Platform engineering, DevOps, SRE: what's the actual difference?

Every few months, someone asks me what I actually do. When I say "DevOps", I get a nod. When a colleague says "platform engineer", the nod is slower. When someone says "SRE", people just smile politely.

The confusing part is that inside the industry, we aren't much clearer. The same job gets posted under all three titles, and the same title can mean three different jobs. So here's my attempt to untangle it.

Why everyone suddenly says "platform"

DevOps started as an idea, not a job title. The idea was simple: the people who build software and the people who run it should stop throwing things over a wall at each other. Shared responsibility, more automation, faster feedback.

Then the idea became a role. Companies hired "DevOps engineers", and very often those people became the new wall. Every team needed something from them: a pipeline, a cluster, a database, a fix. The DevOps team turned into a ticket queue.

Platform engineering is largely a reaction to that. Instead of doing things for every team, you build a product that lets teams do things themselves. Self-service pipelines, templates, environments, all with sensible defaults.

What each role owns, in plain words

DevOps is the culture and the set of practices: automation, CI/CD, infrastructure as code, monitoring, shared ownership. As a job title, it usually means "the person who makes building, shipping and running software work".

SRE (Site Reliability Engineering) came from Google. It treats operations as a software problem. SREs care about reliability with numbers attached: SLOs, error budgets, incident response, reducing toil. Their main question is "how reliable does this need to be, and how do we get there without burning out?"

Platform engineering builds the internal product that developers use to ship software. The customers are your own developers. Their main question is "how do we make the right way the easy way?"

DevOps is the philosophy, SRE is reliability as an engineering discipline, and platform engineering is the product that makes both scale.

Where they overlap in my own work

In practice, the borders are blurry. On a normal week I might write a pipeline template (platform), tune an alert so it stops waking people up for nothing (SRE), and help a team understand why their deployment keeps failing (classic DevOps).

That's normal, especially in smaller companies. Titles describe where your focus is, not a fence around what you're allowed to touch.

The skills underneath are almost the same: Linux, networking, cloud, containers, Kubernetes, infrastructure as code, observability, scripting. What changes is the angle you look from.

Does a small team need a platform team?

Probably not yet. If you have ten developers and one or two people doing operations, you don't need a "platform team". You need a few good templates, a solid pipeline, and decent documentation.

Signs you're ready for a platform approach:

• The same request lands on the ops team again and again.
• Every team builds its pipelines differently, and nobody can help anyone else.
• New services take days or weeks to get into production.
• Developers spend more time on infrastructure than on their product.

When those pile up, a small platform team that treats the developer experience as a product starts to pay for itself.

What I'd tell someone choosing a path

Don't stress too much about the title. The foundations are the same, and you can move between these roles later.

If you love automation and building tools for other engineers, lean towards platform engineering. If you enjoy incidents, metrics and making systems hold up under pressure, SRE might be your thing. If you like a bit of everything, "DevOps engineer" is still a great place to start.

So, which one do you need?

Most teams need the DevOps mindset first. Reliability practices come next, once you have users who notice when things break. A platform team comes when you have enough developers that self-service saves more time than it costs to build.

My take: titles change every few years. Making software easy to ship and hard to break never goes out of fashion.

— Desly