Platform engineering: internal platforms that let teams operate on their own

Asking a development team to build, deploy and run its own service makes a lot of sense: the people who write the code understand best how it fails. But if that team also has to choose a CI/CD tool, write its pipelines from scratch, set up observability, request a database by ticket and figure out how secrets are managed, autonomy turns into overload. Every team solves the same problems its own way, with uneven results in security and reliability.

Platform engineering is the discipline that addresses this: building and running an internal platform that offers those capabilities as self-service, with controls built in, so product teams can focus on their service. The CNCF TAG App Delivery published two public documents on it in 2023: the Platforms White Paper in April and the Platform Engineering Maturity Model in October. This article draws on both.

If your organization is moving to a product operating model, the platform is what makes it viable for many stable teams to operate without multiplying duplicated effort.

What an internal platform is

The CNCF white paper describes a platform as an integrated collection of capabilities, defined and presented according to the needs of its users, who in this case are the teams that build and run applications. The key word is "integrated": a list of disconnected tools is not a platform.

The paper lists attributes that set a useful platform apart:

• Platform as a product: designed and evolved based on what its users need, not on what the infrastructure team wants to build.
• User experience that is consistent across portals, APIs, command line tools or the development environment itself.
• Documentation and onboarding that let teams get started without depending on a specific person.
• Self-service: capabilities are obtained without manual intervention from the platform team.
• Reduced cognitive load: implementation complexity is hidden behind simple interfaces.
• Optional and composable: teams can use the parts they need.
• Secure by default: the organization's controls come built in.

The diagram shows the usual layers and who works on each one.

Golden paths and self-service

A golden path is a recommended, supported route for doing something common: creating a new service, publishing an API, deploying a batch job, connecting a database. It combines a template, the automation that sets it up and the documentation that explains the decisions already made.

For example, a golden path for a web service could generate in minutes a repository with the project structure, a pipeline with tests and security scanning, OpenTelemetry instrumentation already configured, basic dashboards and alerts, the service's entry in the catalog and a first deployment to a test environment. The team starts writing business logic on day one, not after weeks of setup.

Three principles make a golden path work:

• It is the easiest path, not the only one. A team with a different need can step off it, but takes on the cost of running its variant. If many teams step off, the signal is that the path is not working.
• Controls are built in. Dependency scanning, secrets management, audit logging and network policies come with the template. Compliance is the result of following the path, not an extra step.
• It is maintained over time. When a version or a policy changes, the platform team updates the path and provides a way to migrate existing services.

Golden paths also simplify change governance: a deployment that goes through a standard pipeline with automated tests and evidence is a good candidate for a pre-approved change model, as we explain in change enablement without bureaucracy. And the instrumentation included in the template is the foundation for observable applications, not just observable infrastructure.

Minimum capabilities

The CNCF white paper lists thirteen possible capability domains, from portals to artifact storage. No organization needs all of them from the start. The following table proposes a reasonable minimum for a first version, with a concrete signal that the capability is really available as self-service.

Capability	What it provides	Signal that it is ready
Environment and infrastructure provisioning	Compute, networking, databases and queues from declarative templates	A team gets an environment without opening a ticket
CI/CD	Standard build, test and deployment pipelines	A new service deploys to test on day one
Observability	Logs, metrics and traces with default instrumentation and dashboards	Every new service has a dashboard and basic alerts
Security and policy	Code and dependency scanning, policies enforced in the pipeline	Policies are validated automatically before deployment
Identity and secrets	Centralized management of secrets and service credentials	No secret lives in the repository or in manual variables
Portal and catalog	Inventory of services, owners, documentation and access to golden paths	You know who owns each service without asking

Behind many of these capabilities sits infrastructure and configuration automation the organization already has. Reusing it with good versioning and testing practices is faster than rebuilding it.

The platform team

In Team Topologies terms, the platform team provides internal services that stream-aligned teams consume in X-as-a-Service mode. That has practical implications:

• It has a product owner. Someone interviews the user teams, prioritizes the platform backlog and decides what not to build.
• It publishes service commitments. The platform is a critical service: if the pipeline or the secrets manager goes down, every team stops. It needs its own service level objectives, on-call rotation and incident management.
• It combines profiles. Infrastructure, development, security and user experience. A team made up only of administrators tends to build tools for administrators.
• It facilitates adoption. Beyond building, it temporarily works alongside teams that are migrating, in facilitation mode, and learns from their difficulties.

For many infrastructure and operations groups, this is the natural destination for part of the current team: moving from handling tickets to building reusable capabilities. We cover this in from administrators to SRE.

How to measure adoption and experience

A platform nobody uses adds no value, however well built. The CNCF white paper proposes measuring on three fronts:

• User satisfaction and productivity: active users and retention, satisfaction surveys and productivity metrics.
• Organizational efficiency: time from requesting a capability to having it available, time to get a new service into production and time for a new person to make their first change.
• Product delivery: DORA's four metrics (deployment frequency, lead time for changes, time to restore and change failure rate) for the teams using the platform.

We recommend starting simple: a short, periodic survey of user teams, plus usage data for each golden path. The useful question is not "how many tools does the platform have?" but "how many teams choose it and how much time does it save them?".

The Platform Engineering Maturity Model helps you locate where your organization stands. It assesses five aspects (investment, adoption, interfaces, operations and measurement) across four levels: provisional, operational, scalable and optimizing. In the adoption aspect, the progression is telling: from erratic use, to extrinsic push, to intrinsic pull and finally to users participating in the platform themselves. The model makes clear that not every organization needs to reach the highest level in every aspect.

Common mistakes

Some patterns show up often in platform initiatives and are worth avoiding from the design stage:

1. A portal without capabilities. An attractive portal with a catalog goes live, but behind every button there is still a ticket and a wait. The portal is the face of the platform, not the platform.
2. Mandating instead of attracting. Imposing the platform by decree produces adoption on paper and workarounds in practice. It is better for the golden path to be clearly the easiest one and let results do the convincing.
3. Building everything before having users. A platform designed for a year without real teams using it tends to solve problems nobody has. Start with one or two pilot teams and a single complete path.
4. Treating it as a project. If the team disbands after the first version, the platform ages and teams go back to their own solutions.
5. Leaving Security and Compliance out. If controls are not in the golden paths, they show up later as manual reviews that cancel out self-service.
6. Automating the ticket queue without changing it. Turning a manual procedure into a form that triggers a script is progress, but it is not self-service if every step still needs manual approval. To move from manual procedures to auditable automation, see from runbook to playbook.

Because the platform concentrates security controls, production access and change evidence, validate its design with Architecture, Security and Compliance before opening it to every team.