infra, sre, devops, platform engineering: the four-way fork in the road

If you’ve spent any time in this corner of the industry, you’ve seen these four titles used almost interchangeably: Infrastructure Engineer, SRE, DevOps Engineer, Platform Engineer. Recruiters swap them. Job descriptions blur them. Your relatives just call all of it “computer stuff.”

But they’re not the same thing. Not even close.

I’ve sat in more than one of these chairs over my career, and the easiest way I can explain it is with what each role actually loses sleep over:

All four live in the terminal. All four get paged at 3 AM. All four get lumped into “the DevOps person” by everyone outside engineering. But the philosophy behind each one is fundamentally different.

• Infrastructure Engineer — the architect and builder. Cares about the foundation: networks, cloud resources, the plumbing. North star: provisioning and availability.
• SRE — the operator and optimizer. Treats operations as a software problem. North star: reliability within error budgets.
• DevOps Engineer — the bridge and accelerator. Cares about the pipeline between writing code and running it in production. North star: shipping velocity.
• Platform Engineer — the product builder for engineers. Cares about abstracting all the complexity above so developers never have to think about it. North star: developer experience.

Same tools, four different religions.

level 1: junior — where everything looks the same

At the entry level, honestly, these four roles are almost indistinguishable. Everyone is learning the same tools—Linux, bash, maybe some Terraform, maybe some Python. You’re all getting your hands dirty with the same Kubernetes cluster. The difference is subtle but it’s there in what you’re actually paying attention to.

A junior infra engineer is mostly responding to tickets. “Spin up this server.” “Open this port.” “Why can’t this app reach the database?” You’re learning the what: what does this app need to run? If the server is up and the network path is clear, you did your job.

A junior SRE is on the other side of that same system, staring at Grafana dashboards and getting woken up by PagerDuty. You’re not building the infra—you’re watching it break. You’re writing your first automation scripts because you got tired of running the same kubectl commands at 2 AM. You’re focused on the how: how is this thing actually performing?

A junior DevOps engineer is probably the one who set up the CI pipeline that everyone now takes for granted. You’re debugging why the Docker build keeps failing, why the deployment is stuck, why staging and production have mysteriously drifted apart. You’re focused on the flow: how does code get from a developer’s laptop to production without catching fire?

A junior platform engineer—if the company is mature enough to even have this role at the junior level—is building internal tooling. Maybe it’s a CLI that scaffolds new microservices, maybe it’s a Helm chart wrapper that hides the ugly YAML from developers. You’re focused on the who: who is using this infrastructure, and how do I make their life easier?

At this level, the junior infra engineer learns how to build the cloud. The junior SRE learns how the app breaks it. The junior DevOps engineer learns how to ship through it. The junior platform engineer learns who’s suffering because of it.

level 2: mid-level — the fork actually happens

This is where the four roles really start pulling apart. The toolset still overlaps heavily, but what you do with those tools diverges hard.

The mid-level infra engineer stops just spinning up resources and starts designing them. You’re thinking about VPC architecture, hardening Kubernetes clusters, writing Terraform modules that the rest of the org actually reuses. You become obsessed with Infrastructure as Code—not because it’s trendy, but because you want the guarantee that if everything burns down, you can rebuild it with one command. Your metric is whether the underlying platform is healthy. Is the Kubernetes API reachable? Is the database cluster running?

The mid-level SRE doesn’t really care if the database is “running.” They care if it’s fast enough. You start defining SLIs and SLOs—not because someone told you to, but because “it seems fine” stopped being an acceptable answer after that one incident where p99 latency quietly tripled and nobody noticed for a week. You’re writing software to auto-remediate problems. Disk filling up? You don’t file a ticket anymore; you write something that cleans it up before anyone even notices.

The mid-level DevOps engineer is now the owner of the deployment machinery. You’ve moved past basic CI/CD and you’re implementing GitOps with ArgoCD or Flux. You care deeply about deployment strategies—canary, blue-green, progressive rollouts—because you’ve been burned by a bad deploy that took down production on a Friday evening. You’re the person developers come to when they say “it works on my machine” and you have to figure out why it doesn’t work anywhere else. Your metric isn’t uptime—it’s deployment frequency and mean time to recovery.

The mid-level platform engineer has stopped writing one-off scripts and started thinking like a product manager. Your “users” are the other engineers. You’re building an Internal Developer Platform—maybe a self-serve portal where a developer can spin up a new service, get a database, configure DNS, and set up monitoring without filing a single ticket. You’re obsessed with golden paths: opinionated, well-paved defaults that let teams move fast without making bad choices. Your metric is how many tickets the infra team didn’t get this quarter.

The infra engineer asks: “Is the database running?” The SRE asks: “Is it fast enough that users aren’t rage-refreshing?” The DevOps engineer asks: “Can we deploy a fix in under five minutes?” The platform engineer asks: “Why did the developer need to file a ticket at all?”

level 3: senior / staff — four different seats at the table

At this level, all four roles are strategic. But they’re solving completely different classes of problems.

The senior infra engineer is an architect looking 2-3 years ahead. Should we go multi-cloud? How do we design disaster recovery that spans continents? You’re designing the foundational systems that everything else sits on top of. You’re providing capacity—the raw ability for the business to expand into new regions, handle new workloads, and grow without hitting a wall.

The senior SRE is a guardian. You’re the one holding error budget meetings with product managers, telling them they can’t ship that feature next week because the system is already too unstable. You run blameless post-mortems that aren’t just a formality but actually change how teams write code. You’re looking for systemic risk across the entire stack. You’re providing confidence—the assurance that the business can survive its own growth without falling over.

The senior DevOps engineer is an evangelist and a systems thinker. You’re not just maintaining pipelines anymore—you’re shaping engineering culture. You’re driving the adoption of trunk-based development, feature flags, and progressive delivery across the org. You’re the one who connects the dots between “we deploy once a week” and “our incident recovery takes 4 hours” and builds the case for investment in deployment infrastructure. You’re providing velocity—the ability for the org to ship safely, often, and with confidence.

The senior platform engineer is running what is essentially an internal product team. You have a roadmap, you collect feedback from your “customers” (the developers), and you make prioritization trade-offs. You’re designing the abstractions that let a new hire deploy their first service on day one instead of spending two weeks reading wiki pages about Kubernetes. You’re the reason the company can scale from 20 engineers to 200 without the infra team growing proportionally. You’re providing leverage—every hour you invest saves hundreds of hours across the org.

The senior infra engineer enables growth. The senior SRE ensures the business doesn’t collapse from it. The senior DevOps engineer ensures teams can ship through it. The senior platform engineer ensures nobody needs a PhD to use any of it.

the startup reality

In a lot of smaller companies, all four of these people are the same person. One engineer setting up the AWS account, writing the Terraform, building the CI pipeline, configuring the alerts, and making a Slack bot that provisions environments. Usually they’re called a “DevOps Engineer” and they’re doing the job of four roles with the salary of one.

That works until it doesn’t. As the org scales, the cracks show up fast. The person who’s great at designing network architecture isn’t necessarily the right person to build a developer self-serve portal. The person who lives for incident response and error budgets might not care about shaving 30 seconds off a CI build.

so which one are you?

The simplest way I think about it after sitting in multiple of these chairs:

• The Infrastructure Engineer builds the tracks.
• The SRE keeps the train moving at 200 mph without derailing.
• The DevOps Engineer makes sure the train departs on schedule, every time.
• The Platform Engineer builds the booking app so passengers never have to think about tracks or trains.

Capacity. Confidence. Velocity. Leverage. You need all four.