Building Self Service Infrastructure With Governance and Approvals

Companies can build self-service infrastructure by letting users request approved resource types and service parameters while the platform enforces quotas, permissions, approval rules, execution policy, and audit. The source does not define one formal product called a self-service portal, but it provides the operating building blocks this model needs.

Self-service should simplify the request and leave governance in place. Users should not need to know the physical GPU card, switch port, or server command. They should choose an approved service or resource specification, and the platform should decide whether the request is allowed and how it is delivered.

What does self-service mean in infrastructure operations?

Self-service means a user can request or manage an approved infrastructure service without waiting for an operator to perform every routine step by hand.

The source scheduling model already moves in this direction. Users work with standard resource specifications while the scheduler manages heterogeneous physical resources underneath. The workflow engine supports dynamic approval, approved work orders can trigger resource scheduling or automation, and the governance layer controls roles, tenants, projects, and permissions.

Together those capabilities make a self-service operating pattern: the user interacts with the service definition, and the platform enforces the infrastructure rules.

Why should users request a service instead of a physical device?

The user usually needs an outcome, and a specific serial number is beside the point. A developer may need eight compatible accelerators, a defined CPU and memory profile, storage capacity, a project quota, or an inference service. They should not need to know which physical server or GPU card can satisfy the request.

The source scheduling layer converts heterogeneous GPU and NPU resources into standard specifications, and that abstraction is what makes self-service useful. The infrastructure team keeps control of the physical pool, and the user receives a resource service.

What should remain hidden from the self-service user?

Hide details that the user does not need for the decision or that create operational risk. Examples include BMC credentials, raw switch configuration, firmware commands, sensitive management networks, physical power controls, global tenant administration, and high-risk automation scripts.

The source governance model uses least privilege and separate authorization for sensitive operations, and self-service should inherit that boundary. The user can request capacity without automatically receiving the right to change the infrastructure that supplies it.

What should the self-service form contain?

The source workflow engine supports configurable forms and dynamic approvers, so a resource request can capture the parameters required for scheduling and accountability.

Useful fields can include:

• Project
• Tenant
• Resource specification
• Quantity
• Requested duration
• Priority
• Preemptible or non-preemptible policy
• Business reason
• Start time
• End time
• Cost center where used

The exact fields depend on the service, and the source does not prescribe one universal request form. What matters is that the request captures enough information for quota, approval, scheduling, and audit.

How should quotas protect the platform?

Quota should be checked before the request is accepted for normal scheduling. The source scheduling design uses tenant quota as a hard constraint, which lets the organization offer self-service without offering unlimited consumption.

A user may be authorized to request GPU resources inside Project A, and the project may still have a quota on GPU count, accelerator memory, concurrent tasks, and monthly card hours, according to the organization's policy.

If the request exceeds the quota, the platform should show that reason clearly, so the user does not need an infrastructure engineer to find the problem.

How should permissions work?

Permissions determine who can request, approve, view, or operate each service. The source governance layer includes organization, role, permission matrix, tenant membership, project membership, and least privilege.

That allows different self-service roles. A project user can submit a request, a project owner can approve some requests, an infrastructure operator can manage the resource pool, and a platform administrator can define global policies. The exact role names are specific to each organization. The operating principle is that self-service actions stay inside the user's authorized scope.

How should approvals be designed?

Use approval only where it adds meaningful control. The source workflow engine supports dynamic approvers, multi-level approval, timeout, escalation, and automated execution after approval, so a request can be low-touch without becoming uncontrolled.

For example, a small request inside quota may be auto-approved by policy. A larger request may need the project owner, a high-cost request may need an additional manager, and a production infrastructure change may need a separate operations approval.

The source does not define these specific thresholds. The enterprise should map approval depth to risk and cost.

Why should approval trigger execution automatically?

Re-entering an approved request by hand recreates the work self-service was supposed to remove. The source workflow model explicitly supports execution nodes after approval, so the approved form becomes the input to the scheduling or automation action.

The user requests the approved resource specification, the approver sees the exact request, the workflow approves it, the scheduler allocates the resource, and the result is written back. That control chain is much cleaner than submitting a ticket, waiting for approval, waiting for an operator, and then having the operator copy the request into another console.

How should bare-metal delivery fit into self-service?

The source bare-metal delivery model automates the operating system, drivers, monitoring, and cluster registration, and that can become one of the services exposed through a controlled request flow.

The user requests an approved bare-metal profile. The platform verifies the physical server, the workflow provisions the approved image and software stack, and monitoring and inventory update automatically. It is a strong self-service example because the user receives a delivered environment instead of starting a manual infrastructure project.

For the delivery chain, how automated bare metal provisioning works for physical servers, operating systems, GPU drivers, and monitoring agents explains the source-supported steps.

How should GPU scheduling fit into self-service?

The resource catalog should expose standard GPU specifications instead of every device detail. The source scheduler already supports heterogeneous pools, standard resource specifications, quotas, priority, preemption, whole-card and sliced resources, and health-aware scheduling.

The user chooses the approved specification, and the platform finds healthy compatible resources. Self-service can then scale across mixed hardware without teaching every user the details of each accelerator vendor.

How should model services fit into self-service?

The source MaaS layer uses model repositories, deployment templates, inference instances, and API gateway publication, which gives another self-service pattern. An authorized user can select an approved model, an approved deployment template, a resource specification, a project, and service parameters.

The platform can create the inference instance and publish the service under the normal governance controls, so the user does not have to build the full deployment manually.

For the model-service chain, what is MaaS, and how do model repositories, inference instances, API gateways, and Token metering work together explains how the components connect.

How should cost visibility affect self-service?

Users should see enough cost or consumption information to make better requests. The source platform tracks card hours, Token usage, idle rate, project cost, and tenant cost, so a self-service form or project view can show the impact of the requested resource specification.

The source does not specify a required cost-estimation feature at request time, but the same metering model can provide historical unit-cost context. Self-service should not hide the financial effect of expensive infrastructure.

How should queue state be shown?

If the requested resource cannot start immediately, the user should see why. The source scheduler makes queue reasons visible, and they can include quota, an unavailable resource specification, a health exclusion, priority, topology, or fragmentation.

This matters for self-service. Without an explanation, users open tickets asking why the request has not started, and a clear queue reason reduces that operational burden.

How should sensitive actions be separated?

Requesting a resource and changing infrastructure need different levels of privilege. A user may be allowed to request a resource without being allowed to change firmware, modify network configuration, close a cooling valve, change global quotas, or edit another tenant's resources.

The source governance and automation layers use separate authorization for sensitive operations. Keep that distinction, so self-service widens access to approved services while administrative privilege stays where it was.

How should the process be audited?

Every self-service request should stay traceable. A source-grounded audit chain covers the requester, tenant, project, requested service, parameters, quota decision, approver, execution identity, allocated resource, result, and cost or usage record.

The source operation logs also preserve before and after values for changes, so a self-service environment can be highly automated and still auditable.

What should companies implement first?

Start with a small number of high-volume, repeatable requests. Good source-supported candidates include GPU resource requests, bare-metal delivery, quota changes, inference-service deployment, and project access requests.

For each one, standardize the parameters, define quota and approval, connect the workflow to execution, and write the result back.

A platform example that provides these request, quota, workflow, scheduling, and governance building blocks is Sensaka.

If I were building self-service infrastructure, I would not start by giving users more consoles. I would turn the five most common infrastructure tickets into approved service requests with clear parameters, quota checks, automatic execution, and audit. That reduces waiting without weakening control.