Don't Panic — Self-Service Infrastructure

Self-service infrastructure is the respectable name for replacing a recurring request queue with a supported platform capability. Instead of explaining the same database, environment, or access need to a specialist each time, a requester declares approved intent and the platform carries it toward a usable result. The important word is supported. A form that sends someone an email is still a ticket wearing a nicer hat.

The useful mental model has six stops: discover, request, validate, fulfill, report, and operate. Discovery says what the capability is for. The request captures decisions the user understands, such as service class, placement, owner, or expiry. Validation checks identity, policy, quota, and dependencies before anything starts reproducing at cloud speed. Fulfillment talks to providers. Reporting tells the requester what happened. Operation handles the awkwardly long tail: updates, renewal, drift, deletion, and the occasional resource that exists only halfway.

A capability is therefore more than a portal button. It has a contract, controls, automation, durable state, documentation, support, and an owner. The platform hides provider sequencing and organization-wide defaults, but it must not hide progress or failure. An operation identity and explicit states are useful because provider work can outlive a browser tab, a network connection, or a person’s confidence that clicking retry is harmless.

The first surprise is that creation is the least interesting part. A resource without ownership, expiry, and deletion behavior is not a finished outcome; it is an archaeological site with billing enabled. A retry without idempotency can create a second site beside it. A partial failure can leave the database behind after the deployment fails. This is why the lifecycle belongs in the capability contract, not in a hopeful footnote.

A golden path combines documentation, templates, integrated capabilities, and guardrails for a common outcome. It should be attractive because it works well, not compulsory because it is the only door someone remembered to build. Valid needs outside the path need an exception route, or they will find one anyway and it will be considerably less observable.

Start with the Intro for the full request-to-resource model and the controls behind it. Use Slides when you need the layers and decision points at a glance. Keep the Cheatsheet nearby when designing states, failure handling, and measures. Then try the Practice reference and Exercise: they turn the tidy diagram into a capability contract that has to survive an actual request.

Don't Panic — Self-Service Infrastructure

Relevant careers