R ยท Run

Provisioning

Self-service infrastructure for AI work: provision, build, and deploy as one motion rather than three queues.

View as Markdown

Provisioning is the act of creating what a workload needs to exist: compute, database, storage, secrets, ingress, identity, telemetry. The Run question is whether that is one motion or a sequence of requests to different teams.

The queue is the cost

An engineer wants to ship an internal tool. They need a place to run it, a database, a secret, and a hostname. In a lot of organizations that is four requests to three teams, each with its own form and its own idea of what constitutes a complete request.

The interesting cost is not the aggregate wait. It is that the wait is long enough for people to plan around it. Once a two-week provisioning lead time is common knowledge, teams start batching, over-requesting so they do not have to come back, and building workarounds on infrastructure they already have. Every one of those behaviours makes the estate harder to reason about, and none of them appear in a metric.

Provision, build, deploy as one motion

The target state is a single action that produces a running application with everything attached. Not because typing one command is intrinsically better, but because it collapses the decisions into one place where they can be made well once.

What that means concretely:

  • The template owns the defaults. Backup policy, encryption, network placement, log retention, and tags are properties of the template, not of the requester’s memory.
  • Identity comes with it. The workload gets its own identity at creation, so secrets and data access can be scoped to it rather than to a shared account.
  • Teardown is symmetric. Anything creatable by self-service must be destroyable by self-service, including everything it created. Orphaned infrastructure is the tax on systems that only know how to say yes.
  • The record is in version control. What exists should be reconstructable from a repository rather than from a console.

Ephemeral by default

AI work produces an unusual number of short-lived environments: an experiment, a demo, a per-branch preview, a sandbox for one agent session. If those are expensive to create, people keep them, and a kept environment becomes permanent, undocumented infrastructure holding a copy of production data.

Making environments cheap to create and automatic to expire is the single most effective control on estate sprawl. An environment with a deletion timestamp at creation solves a problem that quarterly cleanup projects never will.

Quotas beat approvals

For most requests, an approval step is a slow way of saying yes. A quota is the same control expressed as a budget: teams operate freely inside it, and the conversation only happens when they want more.

Quotas also produce a useful signal. A team that consistently hits its ceiling is telling you something about demand, in a way that a queue of approved tickets never does.

Reserve real approvals for the small set of actions that genuinely warrant one: production data access, public exposure, and spend above a threshold.

Questions to ask your vendor, or your own team

  • How many separate requests does it take to get a running AI app with a database, a secret, and a URL?
  • Can a team destroy everything they created with one action, including the storage?
  • What expires an environment nobody is using?
  • Are backup, encryption, and retention properties of the template, or of the requester?
  • How many AI workloads are running on infrastructure that was provisioned by hand?
  • Where is the list of what exists, and is it generated or maintained?