Platform engineering is the discipline of building and operating an internal platform that development teams use on their own, without asking someone every time. The Cloud Native Computing Foundation (CNCF) describes such a platform as a curated collection of capabilities that a dedicated team maintains like a product [1]. The purpose is quickly stated: a development team should spend its time on its product, not on the twentieth variant of delivery, network approval and logging.
The comparison that usually holds up is the publishing house. A publisher gives its authors a template, an editing desk and a printing process. What goes into the book remains the authors' decision. An internal platform does the same for software: it provides the path, not the product.
This page treats platform engineering as an approach: what a platform is, how it differs from DevOps and cloud engineering, and how to tell whether it helps. Product names appear only in the second-to-last section, and there as an example.
Why teams build this in the first place
The trigger is almost always the same. A company no longer has two development teams, but ten. Each has built its own path into production, because that was the fastest option at the time.
After that, every change costs tenfold. A new check before rollout, a new logging requirement, a change of base image: it has to be explained ten times, built in ten times and followed up ten times.
Whoever does not build it in only becomes visible at the next incident. And then the question is no longer whether the requirement made sense, but why nobody can say where it applies.
The CNCF calls the goal reducing cognitive load [1]. In practice that means: the path into production is built, documented and reviewed once. Prepared paths can already include technical requirements. Teams still need to assess application-specific requirements and responsibilities.
Platform engineering, DevOps and cloud engineering
The three terms are often mixed up. They describe different layers, and the confusion is the reason discussions about them go in circles.
DevOps is a mindset: whoever builds it also runs it. Development and operations do not sit in separate departments with a ticket in between. DevOps says nothing about who provides the tools for that.
Cloud engineering is the foundation underneath the platform: accounts and subscriptions, networking, identity, policies and the question of whether all of it can be repeated. It decides what is possible at all.
Platform engineering is the offering that grows on this foundation: runtime environments, delivery paths, templates, a catalogue. It decides what a team can get without asking.
A rule of thumb for telling them apart: cloud engineering lays out the plot and puts in the utilities. Platform engineering builds the houses people can move into. DevOps is the rule that whoever moves in also cleans.
What a platform is made of
Three building blocks appear in almost every implementation.
- Prepared paths (golden paths). Ready-made routines for recurring tasks. A new service repository is created from a template and comes with pipeline, delivery and base configuration.
- Self-service. Teams request environments, databases or permissions through a defined interface instead of writing a ticket and waiting.
- Catalogue or portal. One place that shows which services exist, who owns them and where their documentation lives.
The order matters. The portal is the most visible building block and the last one. A platform becomes solid through the paths underneath, and those require an infrastructure that exists as code.
How to tell that it works
A platform is not a project with a sign-off, but a product with users. So you measure it like a product.
DORA currently considers five metrics: deployment frequency, change lead time from commit to production, failed deployment recovery time, change fail rate and deployment rework rate, the share of unplanned deployments following production incidents [4].
Add two numbers that concern the platform directly. How long does a new team need until its first own deployment? And how many requests land at the platform team per week? If the second number rises, investigate the causes: additional users, new requirements or gaps in self-service.
Voluntary use is a good signal. Mandatory use alone does not prove the benefit: team feedback, shorter waiting times and fewer manual workarounds also matter.
When it does not pay off
The CNCF maturity model says clearly that every further stage of expansion costs additional money and additional time, and that the highest stage is not a goal in itself [2].
With a few teams, shared templates and a maintained guide may be enough. Whether a more extensive platform pays off depends on recurring effort, waiting times and operational requirements.
Without a foundation it does not pay off either. Whoever still maintains accounts, networking and permissions by hand builds a portal on sand: it then shows things that exist only once.
Example: what such a platform looks like
A common layout, explained with concrete tools. The names are an example, not a recommendation, and each of them is interchangeable.
The runtime environment is Kubernetes, a system that distributes applications in containers across several machines and keeps them running. The infrastructure underneath lives as Terraform code in the repository.
GitLab CI builds and tests the application. A GitOps agent continuously reconciles managed cluster resources with the versioned desired state. In this model, GitOps, automatic correction of deviations is configured explicitly.
The prepared path is a template. A team creates a new repository from it and gets pipeline, delivery, logging and base permissions with it. All of it becomes visible in a catalogue, for example Backstage.
What is not interchangeable in this layout is the question underneath it: does a team get the path without asking, and is this path the most convenient one?
Platform engineering is not a tooling decision. It is the decision to build the path into production once and to maintain it like a product, instead of letting it grow anew in every team.
What you can decide afterwards
- Whether your organisation needs a platform or whether templates and a maintained guide are enough.
- Which of the three building blocks (paths, self-service, catalogue) should come first and which can wait.
- What you will measure in six months to see whether the platform serves its purpose.
Frequently asked questions
Is platform engineering the opposite of DevOps?
No. It is an answer to a problem DevOps creates: if every team handles its own operations, every team handles them differently. Platform engineering provides the shared tools, while responsibility stays with the team.
Do I need Kubernetes for this?
No. Kubernetes is widespread, but a platform can just as well sit on a cloud's managed services. What matters is that there is a prepared path, not which runtime environment lies underneath.
From how many teams does it pay off?
There is no fixed number. A usable signal is the moment the same foundation is being built for the third time in parallel, or the moment waiting times on a central team become visible in the delivery cadence.
What is the difference between a platform and an Internal Developer Platform?
In practice, none. Internal Developer Platform (IDP) is the common name for exactly this internal platform. When building one pays off is covered in a separate article.
Sources
- CNCF Platforms White Paper CNCF TAG App Delivery
- Platform Engineering Maturity Model CNCF TAG App Delivery
- What is platform engineering? Microsoft Learn
- DORA's software delivery performance metrics DORA
- What I Talk About When I Talk About Platforms Evan Bottcher, martinfowler.com, 2018