Self-Service Provisioning

Self-service provisioning lets a user request and receive a supported capability through an automated path with minimal manual intervention. The CNCF white paper treats this as a way to serve multiple product teams with less routine coordination.

If each request requires a fixed amount of manual fulfillment, that effort grows with request volume. Automation can reduce the effort per request, but support, exceptional cases and capacity still require work. Compare unit effort and service quality against the previous arrangement.

Approval, execution and interpretation

Examine approval, execution and interpretation separately. Scripts used by a platform engineer can help fulfillment while leaving the user dependent on a queue. A supported automated path makes the request and its outcome accessible to the user.

• Approval. Does someone have to say yes? Sometimes the answer must be yes for real reasons — cost, data classification, regulatory scope — which is not a failure but does need designing. The way to keep both is to move the judgment earlier: encode the allowed cases as policy so that requests inside the envelope need no approval and only the exceptions escalate.
• Execution. Does someone have to run something? This is the one that hides, because a script that a platform engineer runs on request looks automated from the inside and is a ticket from the outside.
• Interpretation. Does someone have to explain the result? If every provisioned database generates a Slack question, the human is still in the loop — just later and less visibly.

The CNCF model’s custom-process level describes routes learned from other people, inconsistent requests and dependence on provider expertise. Its example of an environment recreated only with specialist help illustrates a risk to investigate, not a measured distribution across organizations.

That early operating model can still be appropriate while a team tests demand and learns requirements. Decide which delays or risks justify further investment.

Requesting is not receiving

At the standard-tooling level, documentation and templates let users identify and request capabilities, while some tasks still require specialist support. This describes an interface pattern, not the level at which most platforms have been measured to operate.

Templates can be part of a service even when users need domain knowledge to apply them. Distinguish learning the supported contract from having to understand the provider’s internal implementation. If teams customize copies, plan how later changes will reach them and who owns that migration.

The model’s self-service level reduces routine dependence on maintainers through guided interfaces. Users still need to understand inputs, outputs and operating limits; abstraction reduces unnecessary implementation knowledge rather than eliminating all learning.

What arrives has to work

The maturity model illustrates a database API returning connection details, a secret location and observability information. These outputs let the user connect and inspect the database. Treat them as an example of task completeness rather than mandatory artifacts for every capability.

Define what the supported task needs for use, access and status inspection. For the database example, safe credential delivery and a usable connection matter as much as successful resource creation. Another capability may use workload identity rather than a retrievable secret, or expose status through an API rather than a dashboard.

Completeness has a second half that specifications tend to skip: what arrives when only part of it worked. Provisioning a capability is several actions against several systems — create the instance, register the secret, attach the network, wire the dashboard — and any of them can fail after the earlier ones succeeded. The request can also fail in the ambiguous way, timing out after the resource was created. A retry that creates another database is a correctness defect in the automated path; users need a way to recover without duplicating resources.

Five parts make the recovery contract concrete. They are design choices to implement and test, not guarantees supplied by a form or a scaffolder.

• A key for each logical operation. Generate it before the first submission, or reserve a handle in a separate step before work begins. Preserve the key through retries and browser reconnection; a new intentional creation needs a new key even when its parameters are identical. Bind request records to the caller or tenant, operation and relevant regional scope, reject incompatible parameters, and store the request durably before execution. Use atomic registration and execution coordination so concurrent retries cannot independently start the same work. State retention and retry limits; after records or downstream guarantees expire, reconcile rather than assuming the old key still prevents duplication. AWS’s EC2 documentation and Builders’ Library explain these distinctions.
• A retry-safe contract for each external step. A front-door key does not make downstream calls idempotent. Store and reuse the step’s provider token where supported. Otherwise reconcile using an operation identifier or a request-specific name or tag, checking that the resource belongs to this request and matches its parameters. If the response containing the operation identifier was lost, that identifier cannot be the only recovery method. Queries may lag creation: use bounded backoff and repeated observations, and never treat a single empty search as proof that creation failed. Keep an explicitly unknown state for investigation when the outcome cannot be established.
• Observable state. Expose requested, running, failed, outcome unknown and complete states through a later query, with the failed step and a safe next action. Check authorization on these reads as well as on submission.
• Resumption after reconciliation. Before continuing, establish which steps succeeded and whether the original execution is still active. Reuse confirmed results; coordinate retries with any cleanup so they do not delete a resource another attempt is adopting. Test duplicate concurrent requests, response loss after creation, browser reconnection and delayed lookup, not only a pause between completed steps.
• A named cleanup owner. Record incomplete resources, their request and billing ownership, and whether cleanup is automatic or needs review. Confirm that a resource is safe to remove; a failed workflow may have created something already in use.

State the service responsibility when offering the capability. A managed engine may be operated by a supplier with platform support and escalation, while product teams own some schema or query decisions. Security and access responsibilities may be shared with central teams. Assign those activities explicitly instead of assuming the user always owns every grant or the platform directly performs every engine task.

At the integrated level, some capabilities arrive by default, such as observability and a project’s runtime space. Define which defaults can be changed, the available alternatives and their support requirements.

Two problems self-service creates

Two design risks accompany easy creation: incomplete lifecycle support and an unclear route for requirements outside the supported path.

Creation can outrun maintenance. Design day 2 operations alongside provisioning: resizing, upgrades, backup, transfer and retirement need usable paths, whether automated or explicitly supported by people.

An abstraction serves a defined set of needs. Document the route for others: configuration, a supported extension, an approved alternative or a reasoned refusal. Composable building blocks can help, provided the resulting combination still meets its control and support requirements.

Further integration costs time and money. The maturity model recommends choosing improvements for their value rather than treating the highest level as a universal target.

Why it is worth the trouble, and how to check

DORA’s summary reports a 5% productivity improvement associated with developer independence in its 2024 research. That reported result is not a forecast for a particular platform or a direct measure of cognitive load. Track outcomes locally, including toil and how much routine work can proceed without waiting for another team.

Use these six checks to identify improvements in the supported journey.

1. How much of the ordinary path can users complete independently? Document required reviews, exceptions and response expectations. Manual fulfillment can be an appropriate early service model even where further automation would help.
2. Does the result supply the information and access required for the supported task? Test that the user can use and inspect the capability.
3. Is there a non-GUI way in? Platforms should “meet their users where they are,” and automation is where much of the work lives.
4. When it fails, can the user understand the state and the next step? Evaluate feedback and the escalation path rather than requiring every user to diagnose every failure alone.
5. What happens when only part succeeds? Test concurrent retries, lost responses and delayed visibility, and verify resource counts and ownership after reconciliation and cleanup.
6. What happens on day 30? Upgrades, resizing, ownership transfer and deletion — on the same terms as creation, automated for the ordinary case and explicitly routed for the rest.

Choose an initial capability with users, considering recurring need, reuse, risk and cost. A small golden path can validate the approach before expanding it. What Happens After the Click explains how provisioning connects to the other parts of a platform.

References

• CNCF TAG App Delivery: Platforms White Paper
• CNCF Platform Engineering Maturity Model
• DORA: Platform engineering
• AWS: Ensuring idempotency in Amazon EC2 API requests
• AWS Builders’ Library: Making retries safe with idempotent APIs
• AWS: EC2 eventual consistency