Platform Engineering vs DevOps vs SRE in 2026: 90% Now Have a Platform

Every few months someone asks me whether they should hire a DevOps engineer, an SRE or a platform engineer, as if the three were competing products on a shelf. They are not. After fourteen years of building infrastructure on AWS, GCP and Azure, the cleanest way I can put the platform engineering vs DevOps vs SRE question is this: DevOps is a set of beliefs about how software should flow, SRE is a specific engineering discipline for keeping that software reliable, and platform engineering is a way of packaging both into a product other teams can use without filing tickets. This post explains each one using the primary sources (Google's SRE books, Team Topologies, the CNCF platform papers, and the DORA reports for 2024 and 2025), shows where they overlap, and ends with the question that matters more than the job title: when is a platform team premature?

Platform engineering vs DevOps vs SRE: the short answer

If you only read one section, read this table. Each row is a claim you can check against the source on the right.

	DevOps	SRE	Platform engineering
What it is	A culture and set of practices for breaking down the dev/ops wall	A job role and framework; Google calls SRE what happens when a software engineer designs an ops team (SRE book)	A team that builds and runs an internal platform as a product (Team Topologies)
Prescriptive?	Deliberately not; context dependent	Yes: SLOs, error budgets, toil limits (SRE workbook)	Partly: golden paths, self-service, secure defaults (CNCF white paper)
Signature artefact	CI/CD pipelines, infrastructure as code	SLOs and an error budget policy	Golden path templates, a portal or API, paved infrastructure
Typical metric	DORA software delivery metrics	SLO attainment, error budget burn, toil	Adoption, developer satisfaction, plus DORA metrics (dora.dev)
How it fails	"DevOps team" becomes a renamed ops silo	Pager rotation with a new title and no 50% cap	Ticket-ops, ivory tower, or a ghost town nobody uses (DORA 2025)

The columns are not mutually exclusive. A healthy organisation usually has all three: a DevOps culture, SRE practices where reliability matters, and a platform that makes the right way the easy way.

What is DevOps, really?

DevOps started as a movement, not a job description. Its core claim is that the people who build software and the people who run it should share goals, tools and consequences, and that delivery improves when changes are small, automated and observable. That is why the most honest DevOps measurement is not a headcount but the DORA software delivery metrics: how often you deploy, how long a change takes to reach production, how often changes fail, and how quickly you recover.

Google's SRE workbook describes DevOps as the broader philosophy and SRE as one concrete implementation of it, summed up in the line "class SRE implements interface DevOps" (SRE workbook, chapter 1). The workbook also notes the differences that matter in practice: DevOps aims at silos across the whole organisation and puts culture first, while SRE has a narrower focus on services and end users and comes with opinionated tools.

The familiar failure: leadership renames the operations group "the DevOps team" and nothing about the hand-offs changes. If your "DevOps engineers" spend their week provisioning things on request, you do not have DevOps. You have ops with a queue. I made the longer case for why the underlying practices still matter, especially now that agents write a share of the code, in DevOps Still Matters in 2026.

What SRE adds: error budgets and a 50% ops cap

SRE is far more specific. Google's original book defines it as "what happens when you ask a software engineer to design an operations team", and gives it two mechanisms that most DevOps writing never pins down (SRE book, introduction).

The first is a cap: Google limits aggregate "ops" work (tickets, on-call, manual tasks) to 50% of an SRE team's time, so the rest goes to engineering that removes the toil. The second is the error budget, defined as one minus the availability target. If your SLO is 99.9%, the remaining 0.1% is a budget you can spend on risky launches, and when it is gone, launches slow down. That turns the endless argument between "ship faster" and "don't break things" into arithmetic.

The arithmetic is simple enough to run in a shell:

# Error budget for a 30-day window at three common SLO targets.
# Budget = (1 - SLO) * minutes in the window. Runs with any POSIX awk.
for s in 99.9 99.95 99.99; do
  awk -v slo="$s" 'BEGIN {
    printf "SLO %s%%: %.1f minutes of error budget per 30 days\n",
           slo, (1 - slo/100) * 30 * 24 * 60
  }'
done

# Output:
# SLO 99.9%: 43.2 minutes of error budget per 30 days
# SLO 99.95%: 21.6 minutes of error budget per 30 days
# SLO 99.99%: 4.3 minutes of error budget per 30 days

Going from three nines to four cuts your monthly budget from 43 minutes to about four. Most teams asking for 99.99% have not priced that in, and forcing that conversation is what SRE is for.

SRE fails in its own way: a team gets the title, inherits the pager, and never gets the 50% engineering time back. At that point it is an on-call rotation, not a discipline.

What is platform engineering, according to CNCF and Team Topologies?

Platform engineering is the newest of the three and the most distorted by vendor marketing, so go to the two sources practitioners actually use.

Team Topologies, by Matthew Skelton and Manuel Pais, defines four team types: stream-aligned, enabling, complicated-subsystem and platform. A platform team treats other development teams as its customers, runs the platform as a product, and aims for a "thinnest viable platform" that can be as small as a wiki page and grows only when the organisation needs more (Team Topologies). That last idea is the most ignored sentence in the field.

The CNCF Platforms white paper defines a platform as an integrated collection of capabilities shaped around its users, and lists the attributes that separate a platform from a pile of tools: platform as a product, good user experience, documentation and onboarding, self-service, reduced cognitive load, optional and composable parts, and secure by default (CNCF Platforms white paper). It is explicit that every organisation already has a platform of some kind, even if it is only documentation for third-party services. Its companion Maturity Model scores five aspects (investment, adoption, interfaces, operations, measurement) across four levels: provisional, operationalized, scalable and optimizing (CNCF maturity model).

The "golden path" is the concept that ties it together: an opinionated, supported route from idea to production (a service template, a pipeline, a deployment target, dashboards and docs) that a team can take without asking anyone. Golden paths are where DevOps practices and SRE defaults get encoded so that every team inherits them. A portal such as Backstage is one common front door to those paths, and I walk through standing one up in the companion guide, How to Set Up Backstage as an Internal Developer Portal.

What DORA found about platforms in 2024 and 2025

The best evidence on whether platforms help comes from DORA's annual surveys. The two most recent reports agree, with an honest warning attached.

The 2024 report found that developers using an internal developer platform reported 8% higher individual productivity and 10% higher team performance, and organisations saw a 6% gain in software delivery and operations performance. The surprise was the other side: throughput fell 8% and change stability fell 14% (TechTarget on DORA 2024). DORA's own capability page describes the pattern as a J-curve: early gains, a dip as the platform adds complexity, then a recovery to a higher level as it matures (dora.dev).

The 2025 report, renamed the State of AI-assisted Software Development and based on nearly 5,000 respondents, makes platforms close to universal. In its words, "platform adoption is nearly universal: 90%", 76% of organisations have at least one dedicated platform team, and 29% run several platforms (DORA 2025 report). Two findings matter for anyone building one. First, "quality internal platforms" is one of the seven capabilities in DORA's new AI Capabilities Model: when platform quality is high, AI adoption has a strong positive effect on organisational performance, and when it is low the effect is negligible. Second, the capability most associated with a good platform experience was clear feedback on the outcome of a developer's tasks, and user-experience features such as automation and responsiveness to feedback lagged behind the technical basics.

DORA also notes that a high-quality platform correlates with a small increase in delivery instability, which it reads as teams taking more risk because recovery is cheap (InfoQ on DORA 2025). That is an interpretation of survey data, not a controlled result; check it against your own change failure rate.

One caveat about the 90%: DORA counts "at least one platform", which by the CNCF definition includes very modest setups. The figure tells you that shared internal tooling is everywhere. It does not tell you that 90% of companies run a mature, product-managed platform.

Did Gartner's 80% platform team prediction come true?

Gartner's widely quoted forecast, from its 2023 software engineering Hype Cycle, was that by 2026, 80% of software engineering organisations would establish platform teams as internal providers of reusable services, components and tools (Gartner press release, 28 November 2023). Later restatements add "large" organisations and a 45% baseline for 2022, which I could not confirm on a Gartner page.

The closest independent measurement is DORA's 76% with at least one dedicated platform team in 2025. That is near enough to call the forecast broadly right on adoption, with two qualifications. DORA's sample is self-selected, and "has a platform team" says nothing about whether that team is any good. Puppet's 2026 State of DevOps report, a Platform Engineering Edition drawn from 820 practitioners, makes the same point from another angle: most organisations already apply AI inside infrastructure workflows, but far fewer run those capabilities reliably at scale (Puppet 2026 report).

When is a platform team premature?

The honest answer is "more often than vendors would like". A platform team is a product team: it needs customers with a shared, repeated problem and a product manager's habits, even if nobody has the title. DORA 2025 names the three ways it goes wrong: "build it and they will come" (no user research, so the platform becomes a ghost town), the ticket-ops trap (a vending machine for infrastructure with no roadmap), and the ivory tower (a central team dictating tools, which breeds shadow IT) (DORA 2025 report).

My rough tests, which are judgement rather than measured thresholds:

• Fewer than three or four stream-aligned teams. With one or two teams, a shared repo of Terraform modules, a pipeline template and a README is the thinnest viable platform. Hiring a platform team to serve two customers usually produces a portal with nothing behind it.
• No repeated request pattern. If the top five tickets to your ops people are all different, there is no golden path to pave yet. If they are all "new service, new database, new pipeline", there is.
• No owner for the product. If nobody will interview developers and say no to features, you will build the ivory tower by default.
• Reliability work still unowned. A platform will not fix services without SLOs. Put SRE practices on the two or three services that matter first; the platform can then make those defaults standard.

The AI angle cuts the other way. If agents open a meaningful share of your pull requests, the golden path is where you encode the tests, scans, policy checks and deploy gates every change must pass. DORA's finding that platform quality decides whether AI helps is the strongest argument I have seen for a platform team, but only if the platform is good. I wrote about what that looks like on Kubernetes in Kubernetes as the Agent Control Plane in 2026, and about infrastructure code specifically in Infrastructure as Code in 2026.

FAQ

Is platform engineering replacing DevOps?

No. Platform engineering is one way to implement DevOps at scale: it packages DevOps and SRE practices into self-service paths so that every team does not have to rebuild them. The culture of shared ownership still has to exist, or the platform becomes another silo.

What is the difference between an SRE and a platform engineer?

An SRE owns the reliability of specific services, using SLOs, error budgets and a cap on manual operations work. A platform engineer builds the shared tooling and golden paths that other teams use to build, deploy and run their own services. In smaller companies the same person often does both.

Do we need a platform team?

Probably not if you have fewer than three or four product teams or no repeated request pattern; a thin platform of templates and docs will serve you better. You likely do once several teams keep solving the same provisioning, pipeline and observability problems by hand, and DORA's 2025 data suggests the quality of that platform decides whether AI tools pay off.

What I would do this quarter

If I were starting from scratch this quarter, I would not hire a platform team first. I would write down the three most common requests developers make, turn the most frequent into a template with a pipeline, SLO and dashboard baked in, and measure whether teams pick it up. I would put real SLOs on the two services customers would notice, so the error budget conversation starts. Only when several teams are asking for the same paved road would I staff a platform team, and I would give it a product owner and DORA metrics from day one. (For transparency: I run PandaStack, an open-source microVM cloud for agent workloads, so I spend my own days on the platform side of this line.) The job titles will keep changing. The questions in the figure above will not.

Related: DevOps Still Matters in 2026, Kubernetes as the Agent Control Plane in 2026 and DevOps Roadmap 2026.