How can companies build self service infrastructure while maintaining governance and approval controls?

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 required for this model.

The important distinction is that self-service should simplify the request, not remove governance. 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 manually.

The source scheduling model already moves in this direction.

Users work with standard resource specifications.

The scheduler manages heterogeneous physical resources underneath.

The workflow engine supports dynamic approval.

Approved work orders can trigger resource scheduling or automation.

The governance layer controls roles, tenants, projects, and permissions.

Those capabilities together create a self-service operating pattern.

The user interacts with the service definition.

The platform enforces the infrastructure rules.

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

Because the user usually needs an outcome, not a specific serial number.

A developer may need:

Eight compatible accelerators
A defined CPU and memory profile
Storage capacity
A project quota
An inference service

They should not need to know which exact physical server or GPU card can satisfy the request.

The source scheduling layer converts heterogeneous GPU and NPU resources into standard specifications.

That abstraction is the basis of useful self-service.

The infrastructure team keeps control of the physical pool.

The user receives a resource service.

What should remain hidden from the self-service user?

Hide details that are unnecessary for the user's decision or create operational risk.

Examples can include:

BMC credentials
Raw switch configuration
Firmware commands
Sensitive management networks
Physical power controls
Global tenant administration
High-risk automation scripts

The source governance model uses least privilege and separate authorization for sensitive operations.

Self-service should inherit that boundary.

The user can request capacity.

They do not automatically receive 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.

A resource request can therefore 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.

The source does not prescribe one universal request form.

The important requirement 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.

That lets the organization expose self-service without exposing unlimited consumption.

A user may be authorized to request GPU resources inside Project A.

The project may still have a quota of:

GPU count
Accelerator memory
Concurrent tasks
Monthly card hours

according to the organization's policy.

If the request exceeds the quota, the platform should show that reason clearly.

The user should not need an infrastructure engineer to discover the problem manually.

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
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.

A platform administrator can define global policies.

The exact role names are organization-specific.

The operating principle is that self-service actions remain 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
Automated execution after approval

That means 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 require the project owner.

A high-cost request may require an additional manager.

A production infrastructure change may require 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?

Because re-entering an approved request manually recreates the work self-service was supposed to remove.

The source workflow model explicitly supports execution nodes after approval.

That lets the approved form become the input to the scheduling or automation action.

A user requests the approved resource specification.

The approver sees the exact request.

The workflow approves it.

The scheduler allocates the resource.

The result is written back.

This is a much cleaner control chain than:

Submit ticket.

Wait for approval.

Wait for operator.

Operator copies the request into another console.

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

The source bare-metal delivery model automates operating system, driver, monitoring, and cluster registration.

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.

Monitoring and inventory update automatically.

This is a strong example of self-service because the user receives a delivered environment rather than 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 rather than every device detail.

The source scheduler already supports:

Heterogeneous pools
Standard resource specifications
Quotas
Priority
Preemption
Whole-card and sliced resources
Health-aware scheduling

The user chooses the approved specification.

The platform finds healthy compatible resources.

That lets self-service 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.

That creates another self-service pattern.

An authorized user can select:

Approved model
Approved deployment template
Resource specification
Project
Service parameters

The platform can create the inference instance and publish the service under the normal governance controls.

The user does not need 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
Tenant cost

That lets a self-service form or project view 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.

The important point is that 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 the reason.

The source scheduler makes queue reasons visible.

Possible reasons include:

Quota
Resource specification unavailable
Health exclusion
Priority
Topology
Fragmentation

That is important for self-service.

Without an explanation, users open tickets asking why the request has not started.

A clear queue reason reduces that operational burden.

How should sensitive actions be separated?

Resource request and infrastructure change are 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
Edit another tenant's resources

The source governance and automation layers use separate authorization for sensitive operations.

Keep that distinction.

Self-service should expand access to approved services, not expand administrative privilege.

How should the process be audited?

Every self-service request should remain traceable.

A source-grounded audit chain includes:

Requester
Tenant
Project
Requested service
Parameters
Quota decision
Approver
Execution identity
Allocated resource
Result
Cost or usage record

The source operation logs also preserve before and after values for changes.

That means a self-service environment can remain highly automated while still being auditable.

What should companies implement first?

Start with a small number of high-volume, repeatable requests.

Good source-supported candidates include:

GPU resource request
Bare-metal delivery
Quota change
Inference-service deployment
Project access request

Standardize the parameters.

Define quota.

Define approval.

Connect the workflow to execution.

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 start by turning 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.