Platform engineering

A team builds an internal developer platform as a product: self-service tools and golden paths that let product teams ship and run their own services without filing tickets.

How it works

As software moved to the cloud, containers and Kubernetes, the number of things a product team must know to ship one service grew: build pipelines, clusters, networking, secrets, monitoring, compliance. DevOps asked teams to “build it and run it” themselves, which often left a few senior engineers doing operations for everyone. Platform engineering answers by moving that complexity into an internal developer platform (IDP), built and run by a dedicated platform team. The CNCF Platforms White Paper defines a platform as “an integrated collection of capabilities defined and presented according to the needs of the platform’s users”: for example a portal, an API or CLI that creates a database or an environment, templates for new services, a delivery pipeline, observability and secrets, each with documentation. Three ideas set it apart from a classic infrastructure team. Self-service: a developer gets a capability through an API, a portal or a pull request, without raising a ticket and waiting for someone to do the work. Golden paths: Spotify’s term for the “opinionated and supported” way to build something, such as a service template that already has CI, logging and alerts wired in; teams may leave the path, but then they support themselves. Platform as a product: the platform team treats developers as its customers, does user research, keeps a roadmap and measures adoption and satisfaction, because a platform that is mandated rather than chosen rarely gets better. In Team Topologies terms, the platform team offers its services X-as-a-Service to stream-aligned teams, and starts with the “thinnest viable platform”, which may be no more than a wiki page listing the services everyone uses.

Think of it as

A hotel kitchen versus a shared kitchen with a front desk. In one, you hand a request slip to the chef and wait. In the other, the equipment, ingredients and recipe cards are laid out so any cook can make the standard dishes on their own, and the kitchen staff spend their time keeping the stations stocked and adding new recipes people ask for.

Reach for it when

Several product teams each rebuild the same pipeline, cluster setup or monitoring, and the copies drift apart
The infrastructure team’s ticket queue is the main thing product teams wait on
Product teams own their services in production but spend much of their time on infrastructure instead of their product
There are enough teams (often dozens of engineers or more) that one shared path pays back the cost of a team to build it

Think twice when

A handful of engineers who can agree on tools over lunch; a shared document and a few scripts may be all the platform you need
Renaming the infrastructure team “platform” while keeping the same ticket queue and locked-down tools
Building a large portal before talking to any of its users
Forcing every team onto one rigid path, including data science or mobile teams whose needs are different

A real example

A company with 15 product teams has an infrastructure team of six that handles about 120 tickets a month: new environments, databases, DNS records, access to dashboards. A new service takes three weeks to reach production. The team tags a month of tickets and finds that “new service” and “new Postgres database” make up almost half. It builds a service template with a pipeline, Kubernetes manifests, logging and alerts already set up, and a database request that is a short YAML file in a pull request, applied by Crossplane after review. It picks two product teams as early users, fixes what they trip over, and only then announces it. Six months later a new service reaches production in a day, ticket volume has halved, and the team, now called the platform team, has a product manager, a quarterly survey of developers and a dashboard of how many services use the template. Teams that need something unusual still file a ticket.

Infrastructure team or platform team?#

Many platform teams start as infrastructure or operations teams. The people and tools can be the same; what changes is how work reaches them and what they count as success.

Question	Infrastructure team	Platform team
What they own	The infrastructure itself: accounts, networks, servers or clusters, databases, often run by hand or with the team’s own scripts	A product on top of the infrastructure: APIs, templates, a portal and docs that other teams use to get infrastructure themselves
Who their customer is	Whoever files a request; the goal is that the systems stay up and the request is closed	Developers in stream-aligned teams, treated as users of a product, with research, a roadmap and a product manager
How work arrives	Tickets: a developer asks, the request waits in a queue, an engineer does it	Self-service: a developer calls an API, fills a form or merges a pull request and gets the result in minutes; tickets are kept for unusual requests
What they measure	Uptime, cost, ticket volume and time to close	Adoption and retention, developer satisfaction (NPS or CSAT), time from request to fulfilment, time to a new hire’s first change, and the DORA delivery metrics of the teams using it
Typical tools	Cloud consoles, Terraform or other IaC run by the team, configuration management, a ticket tracker	The same IaC packaged as modules behind a self-service layer: a developer portal such as Backstage, Kubernetes APIs with Crossplane, GitOps delivery with Argo CD or Flux, service templates, built-in observability and secrets
How it fails	The ticket queue becomes the bottleneck: work that waits on another team’s backlog takes many times longer, and product teams build shadow infrastructure to get around it	A platform nobody adopts: built without asking users, released in one big bang, too rigid for some teams, or mandated so it never has to get better
How to move across	Sort recent tickets by type, and turn the most common request into a self-service template or API; repeat with the next one	Keep treating it as a product: give each capability an owner, keep it optional, and retire or rework parts few teams use

Evan Bottcher (2018) found that tasks waiting on another team’s backlog were 10 to 12 times slower in elapsed time; DORA lists “ticket-ops” and “build it and they will come” among the common platform pitfalls.

Platform engineering, DevOps and SRE#

The three overlap and are often confused. They answer different questions, and one organization can use all three.

DevOps

culture

Developers and operations share responsibility for running software, summed up as “you build it, you run it”. It says who is responsible, not how teams should cope with the growing amount of infrastructure each one must understand.

Site reliability engineering

reliability

Google’s answer to running large services: “what happens when you ask a software engineer to design an operations team.” SREs cap operational work at half their time and spend the rest on automation. Google’s SRE book calls SRE “a specific implementation of DevOps with some idiosyncratic extensions.”

Platform engineering

internal product

Makes “you build it, you run it” workable at scale by giving product teams a self-service platform, so each team doesn’t need its own Kubernetes, networking and security experts. The platform itself still needs operating, often with SRE practices.

What goes into an internal developer platform#

The CNCF Platforms White Paper lists capabilities a platform may offer. Few platforms offer all of them, and the paper advises using existing tools and services before building new ones.

Portal and docs

front door

A web portal or catalog of services, owners, docs and templates. Backstage, open-sourced by Spotify in 2020, is one example.

Golden path templates

new projects

Ready-made starting points for a new service or pipeline, with build, deploy, logging and alerts already wired in.

APIs for infrastructure

self-service

Ways to ask for a database, queue or environment declaratively, for example Kubernetes custom resources with Crossplane, or reviewed IaC modules.

Build and delivery

CI/CD

Shared build, test and deployment pipelines, such as Tekton, Jenkins or GitOps with Argo CD or Flux.

Observability and security

built in

Metrics, logs and traces, secrets, identity and policy checks set up by default, so every team gets them without asking.

Worth exploring

WebsitePlatform tooling landscapePlatformEngineering.orgA filterable map of tools for building an internal developer platform. Each tool sits in one of five “planes” (developer control, integration and delivery, resource, observability, security) and a category such as IaC, CD pipeline, secrets or developer portal, with a one-line description. Vendors can submit their own tools, so treat it as a list of what exists rather than a ranking.

WebsitePlatformEngineering.orgThe Platform Engineering communityA community hub for teams that build internal developer platforms: a blog, a Slack workspace, the PlatformCon conference, courses, and a map of platform tooling.

All resources →

Often confused with

Team structures Platform as a service (PaaS)Infrastructure as code CI/CD pipelines

Where it came from2006–2025

For a long time, developers wrote code and handed it to operations or system administrators, who ran it. When AWS made infrastructure programmable in 2006, DevOps grew up around the idea that the team that builds a service should run it. Google described its own answer, site reliability engineering, in a book on how it runs production systems. In 2018 Evan Bottcher, writing on Martin Fowler’s site, described a company where small infrastructure changes took weeks or months to pass through specialist teams, and defined a digital platform as “a foundation of self-service APIs, tools, services, knowledge and support … arranged as a compelling internal product.”

Matthew Skelton and Manuel Pais’s Team Topologies (2019) gave the platform team a place in the organization: a team that provides services to stream-aligned teams with as little interaction as possible, to reduce their cognitive load. In 2020 Spotify open-sourced Backstage, the developer portal its engineers used to manage over 2,000 backend services, and described its Golden Paths, written to end what it called “rumour-driven development.” The same year Kaspar von Grünberg coined the term internal developer platform, and by 2021 platform engineer had become a common job title, with a community at PlatformEngineering.org.

In April 2023 the CNCF’s Platforms working group published its Platforms White Paper, defining a platform and listing its attributes and capabilities. Gartner predicted that by 2026, 80% of large software engineering organizations would have platform engineering teams, up from 45% in 2022. DORA’s research then tested the promise: platforms raised productivity, but could lower throughput and stability if badly run, and by 2025 it reported that 90% of organizations used an internal developer platform and 76% had dedicated platform teams.

Why it’s built this way

Self-service instead of tickets: Work that waits in another team’s backlog is slow, and the waiting grows with every team it passes through. Bottcher wrote that a platform “must provide services that do not require tickets to be raised and work to be assigned.”
Treat the platform as a product: Platforms “cannot stand on a mandate alone”: one is worth having when using it is easier than building your own. So platform teams do user research, keep a roadmap and measure satisfaction, like any product team.
Golden paths, not golden cages: Spotify’s Golden Path is the “opinionated and supported” way to build something, not the only way. The CNCF paper asks for platforms to be optional and composable, so teams with unusual needs can use only some of it.
Start with the thinnest viable platform: Team Topologies and DORA both advise starting small, with just enough capability for the most common workflow, and growing it from what users need, rather than releasing a large platform all at once.

Timeline

2006
AWS launches, making infrastructure programmable
2018
Evan Bottcher’s “What I Talk About When I Talk About Platforms”
2019
Team Topologies defines the platform team
2020
Spotify open-sources Backstage (March) and describes its Golden Paths (August); the term internal developer platform is coined
2021
Platform engineer becomes a mainstream job title
2023
CNCF publishes its Platforms White Paper (April)
2025
DORA: 90% of organizations use an internal developer platform

Sources9

Improve this page on GitHub