DevOps, SRE and platform engineering: what the difference is.
All three turn up in the same job ad, the same proposal and the same slide. They solve different problems, and swapping one for another costs you a whole team doing the wrong thing competently.
The short answer.
DevOps is a way of working. SRE is an engineering discipline with a number in the middle of it. Platform engineering is an internal product. One says how the team delivers, the second says how much failure is acceptable, the third says what the team no longer has to build on its own.
The confusion has a concrete cause: all three use the same tools. Pipelines, containers, infrastructure as code and monitoring show up in all of them. But the same tool does not mean the same problem, and the question that separates the three is not "which tool do they use" — it is "what is this person judged on improving".
The three, one at a time.
How the team delivers
AWS defines DevOps as the combination of cultural philosophies, practices and tools that increases an organization's ability to deliver applications and services at high velocity. The central point is taking down the wall between the people who build and the people who operate.
Named practices: continuous integration, continuous delivery, microservices, infrastructure as code, monitoring and logging, and communication between teams.
Judged on: the time between writing the code and it being in production, and how much of that is automatic.
How much failure is acceptable
Google's book sums up the origin in a sentence: SRE is what happens when you ask a software engineer to design an operations team. It is not operations with a new name — it is operations written as software.
Two concrete rules: Google caps the aggregate operational work of its SREs at 50%, and treats 100% as the wrong reliability target for basically everything.
Judged on: the system staying inside the agreed availability target, and the error budget being spent on purpose.
What nobody has to build twice
The CNCF defines a platform for cloud-native computing as an integrated collection of capabilities, defined and presented according to the needs of the people who use it. The quotation the CNCF itself adopts describes the result: a foundation of self-service APIs, tools, services, knowledge and support, arranged as an internal product.
The attributes it names include platform as a product, self-service, documentation and onboarding, reduced cognitive load, an optional and composable offering, and secure by default.
Judged on: internal adoption. A platform teams route around is a cost, not a product.
Side by side.
| Question | DevOps | SRE | Platform |
|---|---|---|---|
| What it is | Culture, practices and tools | An engineering discipline | An internal product |
| Unit of measurement | Deployment frequency and lead time | Availability target and error budget | Adoption by internal teams |
| When it arrives | From the first deploy | When downtime costs money | When several teams repeat the same work |
| The sign it went wrong | It became the name of the team that owns the pipeline | It became on-call with no written target | Teams route around the platform |
Which one your company needs now.
Three questions, in order. The first one you answer "no" to is where your problem is.
Does a one-line fix reach production the same day?
If not, the problem is DevOps and no SRE hire fixes it. Pipelines, automated tests and infrastructure as code come before any conversation about reliability.
Can you say, as a number, how long the system may be down per month?
If not, the problem is SRE — and it starts with writing the target, not with hiring somebody. With no target there is no error budget, and with no error budget the priority between shipping and stabilizing becomes a matter of opinion.
Are different teams solving the same infrastructure problem in different ways?
If they are, and there are several of them, then a platform makes sense. With a single team, an internal platform is a product with one user — maintenance cost with no gain in scale.
The mistake we run into most.
A company hires a platform before it has DevOps. The result is always the same: a handsome internal portal on top of a manual delivery process. The teams carry on opening tickets, now with a screen in the middle, and the platform becomes one more thing to maintain.
The second most common: calling the existing on-call rota SRE. The business card changes and the work does not — because there is no written availability target, nobody derived any error budget, and the cap of half the time on operational work that Google uses was never applied. The person firefights with a better title.
The order that works is the dull one: automate delivery, write the availability target, measure, and only then build paved paths for what already repeats. Each of those stages pays for itself, which is exactly the argument for skipping none of them.
Questions about DevOps, SRE and platforms.
What is the difference between DevOps and SRE?
DevOps is a combination of culture, practices and tools for delivering software at speed, taking down the wall between development and operations. SRE is an engineering discipline that puts a number on it: it sets an availability target, derives an error budget from it, and uses that budget to decide when to ship and when to stop. DevOps says how to work; SRE says how much failure is acceptable and what to do when the limit is spent.
What is an error budget?
It is the inverse of the availability target. Google's SRE book defines the error budget as one minus the availability target: a 99.99% target leaves 0.01% of unavailability to spend in the measured period. While budget remains, the team ships. When the budget runs out, reliability becomes the priority until it recovers.
Why is 100% availability the wrong target?
Because Google writes exactly that: 100% is the wrong reliability target for basically everything. Each additional nine costs far more than the last, and beyond a certain point the user notices no difference, because their network, their phone and their provider already fail more often than your system does.
What is platform engineering?
It is treating internal infrastructure as a product. The CNCF defines a platform for cloud-native computing as an integrated collection of capabilities, defined and presented according to the needs of the people who use it. In practice: self-service, documentation, paved paths, and less cognitive load for the people building.
Does my company need all three?
Almost never at the same time. DevOps comes first because it is a way of working and does not require a new team. SRE arrives when there is something in production whose downtime costs money and somebody has to answer for it with a number. A platform arrives when enough teams are repeating the same infrastructure work that building the paved path once is worth it.
Can I hire an SRE without an availability target defined?
You can hire the person, but they become an on-call rota with a new name. With no availability target there is no error budget, with no error budget there is no criterion for prioritizing reliability against features, and the whole discipline turns into firefighting. The target comes before the hire.
Not sure which of the three you are stuck on?
The diagnostic answers that with evidence: where delivery stops, how much the system is down, and what already repeats enough to become a paved path. Two weeks, one document, one fixed quote.
Sources
The definitions and the two numbers cited — the 50% cap and the error budget — come from these three primary sources, opened on August 9, 2026.