Platform interfaces and tenancy
Offer a small reliable platform contract while controlling identity, resource allocation, isolation, and the scope of shared failures.
On this page
The question for today
What you’ll understand
- Specify a platform capability as a versioned behavioral contract.
- Separate authorization, quotas, and workload isolation.
- Calculate allocatable capacity and bounded provisioning lead time.
A platform should provide dependable capabilities without forcing teams to rediscover infrastructure. Users still need request identity, cost, readiness, and failure explanations. In a shared AI platform, tenancy adds another obligation. One team's experiment must not silently gain another team's credentials, monopolize scarce accelerators, or turn a local failure into a platform-wide control-plane incident.
Design the interface around a complete lifecycle
Define a platform capability through inputs, validation, observable states, outputs, and deletion semantics. For a training job, these might include an immutable image, dataset version, accelerator class, maximum duration, and artifact destination. The request should receive a stable identity even when provisioning is asynchronous. Distinguish accepted, queued, provisioning, running, failed, and completed states so a user does not have to infer progress from whether a machine happens to exist.
A useful abstraction supports common work while exposing consequential limits. State maximum runtime, supported checkpoint behavior, data-access scope, and which failures the platform retries. Version the contract when these meanings change. Avoid exposing every provider flag as a supposed self-service interface, but provide an escape or extension path with ownership when a legitimate workload exceeds the standard capability. A platform's success is measured by outcomes for users, not by how much YAML it generates.
Separate three different tenant controls
Kubernetes namespaces are useful organizational and policy scopes, but namespaces alone do not provide complete isolation between mutually untrusted tenants. Network controls, workload restrictions, node placement, and sometimes stronger execution boundaries are separate decisions. Choose them from the tenant trust model. A platform serving one cooperating organization can make different choices from a public service that runs arbitrary customer code. Document which boundary is promised instead of relying on the word namespace.
RBAC authorizes operations through permissions granted to identities; Kubernetes RBAC permissions are additive and do not provide explicit deny rules. A quota addresses resource consumption, not whether a user may read another object's sensitive data. Conversely, denying an API operation does not reserve accelerator capacity for a team. Review identity and authorization, allocation and fairness, and runtime isolation as separate dimensions, with a negative test for each promised restriction.
Budget shared capacity and shared failure
Make physical inventory, system reserve, and tenant allocations visible in consistent units. A quota is an upper bound on requested allocation, not proof that the hardware is currently healthy or available. Allocating every nominal accelerator leaves no room for maintenance, failed nodes, or an urgent recovery job. If overcommit is deliberate, explain priority, preemption, and waiting behavior so teams can plan a job rather than discovering the policy only when capacity is scarce.
Control-plane work also needs tenant boundaries. A team submitting thousands of malformed jobs can consume validation and reconciliation capacity even if no workload starts. Apply bounded request rates, fair queues, and observable rejection reasons. Give platform owners a way to stop one tenant's runaway activity without disabling all service. Test deletion and account offboarding: unfinished jobs, retained artifacts, access grants, and billed allocations must each reach a deliberate terminal condition.
Work it through
Define a training capability with an honest capacity contract
A homogeneous pool has 96 healthy accelerators. The platform reserves 16 for maintenance and recovery. Three tenants request 24 each. A new request takes two seconds for admission, three minutes in queue, ninety seconds to provision, and twenty-eight seconds to validate.
Tenant-allocatable inventory is 96 − 16 = eighty accelerators. The three requests total 3 × 24 = seventy-two, leaving eight unallocated within this budget.
A fourth request for sixteen accelerators cannot fit without waiting, changing reservations, or explicitly using an overcommit or preemption policy. Available budget is eight, not the machine inventory of ninety-six.
Convert the time terms to seconds: 2 + 180 + 90 + 28 = 300 seconds, or five minutes, from valid request to usable capacity on the stated serial path.
Report that five-minute outcome with its queue and provisioning components. Do not label a request ready merely because admission accepted it, and do not promise the capacity calculation covers topology constraints.
The contract can expose both an eighty-accelerator allocation budget and a measured five-minute readiness path without hiding their assumptions.
The living notebook
Explore the model
Interactive lab · queue
Inspect a shared admission queue
Treat λ as accepted provisioning requests and μ as completed requests in the fluid backlog max(0, 4 + (λ − μ)t). The separate M/M/1 mean requires Poisson arrivals and exponential single-server service. The model has no tenants, priorities, heterogeneous accelerators, authorization checks, or fair scheduler.
- Fluid backlog
- 4
- Net rate · λ − μ
- −1 /s
- M/M/1 mean residence
- 1 s
Fluid backlog starts at 4 and follows max(0, 4 + (λ − μ)t). The separate M/M/1 residence-time formula assumes Poisson arrivals, exponential service and λ < μ. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forA usable platform contract includes waiting and overload behavior, not just a request schema.
Pause & reason
Check your understanding
Your turn
Try it yourself
A homogeneous healthy pool has 64 accelerators, with eight reserved. Existing allocations are 20, 18, and 12. Can a new eight-accelerator request be admitted under the no-overcommit budget? Name a second scheduling constraint the arithmetic ignores.
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Subtract reserve and then total the allocations before considering the new request.
Compare with the solution
The allocatable budget is 64 − 8 = fifty-six. Existing allocations total fifty, leaving six; an additional eight would exceed the budget by two. It must wait or use an explicitly different policy. Even a request that fits the count might fail a topology requirement, device-memory requirement, placement restriction, or network-locality constraint. Counts alone do not establish schedulability.
Keep the idea
Take it with you
- Specify a capability through its full observable lifecycle.
- Authorization, resource fairness, and execution isolation are separate promises.
- Budget healthy compatible inventory and expose waiting behavior explicitly.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.