DevOps is the practice: developers and operations share responsibility for getting software to production and keeping it there. SRE is one way to run the operations side, with software engineers, reliability targets and error budgets. Platform engineering builds the internal product (paved paths, a portal, templates) that lets every team do DevOps without each one reinventing it. Most growing companies need all three, in that order.
I’ve spent 18+ years in platform engineering, DevOps and SRE, and in that time I’ve watched the three words become job titles for the same person. That’s fine on a résumé. It’s a problem when you’re deciding what to hire or buy, because each one answers a different question.
What is DevOps, really?
DevOps is an agreement: the people who build a service also care about how it runs, and the path from commit to production is automated, repeatable and fast. CI/CD pipelines, infrastructure as code and monitoring are the machinery that makes the agreement workable.
The cleanest test of whether it’s working is DORA’s software delivery metrics. DORA groups them into throughput (change lead time, deployment frequency, failed deployment recovery time) and instability (change fail rate, deployment rework rate), and its guide states that “speed and stability are not tradeoffs”. If you deploy faster and break more, DevOps isn’t working yet. The DORA metrics post shows how to pull those numbers from your own pipeline.
What is SRE, and how is it different from DevOps?
Site reliability engineering is Google’s answer to the operations half. The definition from the SRE book is still the clearest: “SRE is what happens when you ask a software engineer to design an operations team.”
Two mechanisms separate it from a traditional operations team. The first is a cap on operational work. Google “places a 50% cap on the aggregate ‘ops’ work for all SREs”: tickets, on-call and manual tasks. The rest of the time goes to engineering that removes the need for that work, and when ops work goes over the cap it flows back to the development team. The second is the error budget. The book argues that “100% is the wrong reliability target for basically everything”. The business sets an availability target, and the error budget is one minus that target. While budget remains, teams ship. When it runs out, reliability work comes first.
So SRE is a specific, opinionated implementation of DevOps for running production. You can do DevOps without SRE. Doing SRE without DevOps is very hard, because the error budget only works if developers share the consequences.
What is platform engineering?
It treats internal infrastructure as a product whose users are your developers. 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”, a “cross-cutting layer” for capabilities that many applications need.
In practice that means paved paths: templates that create a new service already wired to CI/CD, observability and the deploy pipeline. It means a portal, often Backstage, with the service catalog, API docs, ownership, deploy status and self-service actions in one place. It means a standard way to move a release from dev to production, with gates, and guardrails like security scans, cost visibility and policy built into the path instead of added by each team.
It exists because of scale. With three teams, each can own its pipeline. With thirty, thirty slightly different pipelines become the bottleneck, and every team spends its time on plumbing instead of product.
How do the three compare side by side?
| Aspect | DevOps | SRE | Platform engineering |
|---|---|---|---|
| Question it answers | How do we ship safely and often? | How reliable must this be, and who fixes it? | How do many teams ship without rebuilding the plumbing? |
| Main artifact | Pipelines, IaC | SLOs, alerts, runbooks, postmortems | Portal, templates, paved paths |
| Measured by | DORA metrics | SLOs and error budget | Adoption by developers, plus DORA across teams |
| Users | The team itself | The service and its users | Internal developers |
Which one does my company need first?
Whatever hurts most today.
If releases are manual, slow or scary, start with DevOps basics: a push gate, CI/CD, infrastructure in code, release by tag. Nothing else sticks without them.
If releases are fine but production breaks and nobody knows until a customer says so, you need SRE. Signals wired, a few SLOs that describe what users feel, alerts you’ve watched fire, runbooks.
If every team does everything its own way and onboarding a service takes weeks, you need platform engineering: one paved path, a catalog and self-service.
A common mistake is buying a portal before the delivery basics exist. A Backstage catalog that lists services with broken pipelines is a nicer view of the same problem. I wrote about how assessments start in The Platform Radar: the engineering leader tells me the team has Kubernetes, Terraform, a CI/CD pipeline and some form of monitoring. A list of tools tells you what was bought. It doesn’t tell you which of the three jobs is actually being done.
Do I need separate teams for each?
Usually not before you have several product teams. A single platform engineer who understands all three can lay the foundations, as long as the work is scoped. On MPI’s portfolio-analytics SaaS platform, the shape over the last 90 days was one Clouditive platform engineer working with an AI agent, alongside the client’s DevOps lead and about eight client engineers. That was enough to build the promotion pipeline, the portal and the alerting, because the developers kept owning their services. Production releases went from about one a week (April to July 2026) to nearly four a week, and failed production release pipelines from 23% to 4%.
What doesn’t work is naming someone “SRE” and giving them only tickets. Without the cap on operational work, SRE turns back into a traditional operations team with a new title.
Is SRE the same as DevOps, and is platform engineering replacing it?
No to both. DevOps is the shared responsibility and the delivery practice. SRE is a concrete way to run production inside it, with targets and budgets, and many SREs do DevOps work every day, which is why the titles blur. Platform engineering packages DevOps practices so more teams can use them without building them. If the platform team stops listening to developers and starts issuing mandates, it becomes the old operations silo again, which is exactly what DevOps tried to remove.
Write down the one thing that hurts most this quarter: release speed, production incidents or team-by-team sprawl. Pick the matching first step from above and scope it to two weeks. If the answer is sprawl and you’re looking at an internal developer portal, the platform engineering page explains what IDP Foundations builds (USD 5,000, two weeks) and the case behind it. SRE / Observability Foundations is also USD 5,000 and CI/CD & IaC is USD 4,000, both two weeks, and every package is on our pricing page.
Sources, accessed 2026-10-07: DORA, software delivery performance metrics, Google SRE book, Introduction, CNCF Platforms White Paper.