Self-Service Infrastructure
Self-service infrastructure lets authorized users request and manage approved computing resources through automated interfaces. Platform teams define the available choices and guardrails, while users receive resources without waiting for each request to be fulfilled manually.
itPlatform engineering and SRE | OpenSkills.info
Intro
Self-Service Infrastructure
Infrastructure requests often begin as tickets. A developer describes a database, environment, network, or deployment need. An operations specialist interprets the request, applies organizational rules, provisions the resource, and reports the result. This process can work at low volume. It becomes a queue when many teams need the same capabilities.
Self-service infrastructure replaces the recurring handoff with a supported product. A platform team defines a capability, exposes a clear request interface, automates fulfillment, and keeps the resulting resource observable throughout its lifecycle. An authorized user can request an approved resource without waiting for a platform engineer to execute every step.
Self-service does not mean unrestricted access to a cloud account. The platform constrains what users can request, validates their input, applies policy, records the operation, and returns useful status. The user controls an approved intent. The platform controls how that intent becomes infrastructure.
The request-to-resource mental model
Treat a self-service capability as a contract between a user and a platform:
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://tag-app-delivery.cncf.io/whitepapers/platforms/
Supports
- Platform definition, value, users, capabilities, providers, and thin-layer guidance
- Self-service, golden paths, documentation, interfaces, secure defaults, and cognitive load
- Platform product ownership, user feedback, adoption, implementation risks, and measures
- https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/
Supports
- Independent maturity aspects for investment, adoption, interfaces, operations, and measurement
- Contextual maturity decisions, vertical product iteration, and socio-technical balance
- https://backstage.io/docs/features/software-templates/
Supports
- Template discovery, inputs, review, execution, task status, cancellation, failures, and results
- https://opengitops.dev/
Supports
- Declarative, versioned, pulled, and continuously reconciled desired-state principles
- https://www.openpolicyagent.org/docs
Supports
- Policy as code, structured input, policy decisions, and separation of decision from enforcement
- https://google.aip.dev/155
Supports
- Request identifiers, deduplication, safe retries, and idempotency guarantees
- https://github.com/sindresorhus/awesome
Supports
- Required starting point for awesome-list discovery
- https://github.com/toptechevangelist/awesome-platform-engineering
Supports
- Discovery of Kratix, Score, OpenChoreo, and CNOE as platform-engineering ecosystem projects
- https://docs.kratix.io/main/reference/promises/intro
Supports
- Promise APIs, workflows, dependencies, destination rules, and resource fulfillment
- https://docs.score.dev/docs/score-specification/score-spec-reference/
Supports
- Workload definition, containers, services, and resource dependencies
- https://openchoreo.dev/docs/overview/architecture/
Supports
- Modular internal developer platform architecture, planes, APIs, and reconciliation
- https://cnoe.io/docs/overview/technology
Supports
- Community reference patterns and common tools for internal developer platform capabilities
