Platform engineering vs DevOps: what is the difference?
With one product team, DevOps works: the team writes its own pipeline, infrastructure code and alerts. With five teams you get five pipelines, five ways to create a database and a queue of tickets for new environments. Platform engineering answers that second situation. It does not replace DevOps.
How is platform engineering different from DevOps, and when do you need it?
Quick answer
Platform engineering vs DevOps: DevOps is a way of working in which each product team builds, ships and runs its own software. Platform engineering is a dedicated team that builds an internal platform, run as a product, so many teams share templates, environments and guardrails. Agnotic Technologies builds that first platform for a client team to own.
| Criterion | Team-level DevOps | Platform engineering |
|---|---|---|
| Number of product teams | Few enough that agreements made in conversation still hold | Enough teams that shared practices need a product to carry them |
| Pipelines | Each team's pipeline differs but is maintained | Teams copy pipelines, and fixes never reach the copies |
| Environments | Teams create their own environments in minutes | Teams file tickets and wait for an environment, a database or access |
| Security controls | Few controls, applied the same way by each team | Controls differ per team and audits find gaps between them |
| Infrastructure code | Each team's modules are small and understood | Several teams maintain near-identical modules for the same resources |
| Onboarding | New engineers learn one setup | Moving between teams means learning a different toolchain |
| Infrastructure load on teams | Teams run their own services without strain | Teams spend more time on infrastructure upkeep than on product work |
| Investment | No budget yet for a dedicated team | Leadership will fund a team to build and run the platform as a product |
What they are
What is Team-level DevOps
Team-level DevOps means each product team builds, deploys and runs its own software and chooses its own pipeline, infrastructure code and monitoring. It keeps teams fast and independent, and it works well while there are few teams and few shared controls.
What is Platform engineering
Platform engineering is a dedicated team that builds and runs an internal developer platform: templates, environments, infrastructure modules, observability and a portal that product teams use through self-service. The platform is run as a product, with users, a roadmap and adoption that is earned rather than mandated.
Key differences
Is platform engineering replacing DevOps?
No. The CNCF Platforms white paper describes platform engineering as emerging in enterprises as an explicit form of the cross-functional cooperation DevOps promised. Product teams still build, ship and run their software. The platform takes over the undifferentiated parts, such as how a new service gets a pipeline, a database or a log stream.
What does an internal developer platform contain?
CNCF defines a platform as an integrated collection of capabilities defined and presented according to the needs of the platform's users. In a first platform that usually means service templates, environment creation, infrastructure modules, default observability, secrets and access, and a portal. Backstage, an open source framework for building developer portals, is a common choice for the portal and its software catalog.
What is a golden path?
A golden path is the supported way to do a common job, such as building, testing, deploying and observing a web service. CNCF describes it as an initial project template offered with documentation. It is the default, not the only road: a team with a good reason can leave it, and the platform team learns from why they did.
How do you measure a platform?
Measure its users and their delivery. Adoption by choice, the time for a new service to reach production, the number of environment tickets and developer satisfaction show whether the platform helps. DORA's delivery metrics, compared per team before and after adoption, show whether it speeds delivery up or just adds a layer.
Where do platform teams go wrong?
Two patterns come up most. A platform built without talking to its users ships features nobody asked for. A mandatory platform with no escape hatch forces every team onto one path and turns the platform team into the new ticket queue. CNCF's Platform Engineering Maturity Model grades adoption from erratic and extrinsic push to intrinsic pull and participatory. Aim for pull.
Who builds the first platform?
Usually a small group drawn from the product teams, sometimes with outside engineers. Agnotic Technologies builds the first version alongside your engineers, documents it and hands it to the team that will run it, so the platform has an owner from the first day.
When to use each
When to use Team-level DevOps
- A small number of product teams that rarely share infrastructure.
- Products on such different stacks that a shared template would not fit.
- An early company still learning which tooling it needs.
- Teams with the skills and time to own their own infrastructure.
When to use Platform engineering
- Product teams copy each other's pipelines and infrastructure code, and the copies drift.
- Developers wait on tickets for environments, databases or access.
- Security and compliance controls differ from team to team.
- Engineers moving between teams must learn a new toolchain every time.
What goes into a first internal developer platform?
Service template. A repository template with build, test, scan and deploy already working, so a new service reaches staging on its first commit.
Environments on request. Preview and staging environments created from the same infrastructure code as production, and removed when the branch closes.
Infrastructure modules. Versioned modules for the resources teams ask for most, such as databases, queues and storage buckets, with tagging and encryption on by default.
Observability by default. Logs, metrics, traces and alert routing wired into every service the template creates.
Access and secrets. Single sign-on, role-based access and a secrets store, so nobody passes credentials around in chat.
Portal and catalog. One place to find services, their owners and documentation, and to request what the templates provide.
Feedback loop. A public roadmap, office hours and usage data, because the platform is a product with internal customers.