Site Reliability Engineer, Platform Engineer, DevOps Engineer - what's the difference?
It's become sort of clickbait for everyone to rant about how DevOps is not a thing or how organization have wrong ideas on what does it mean to do DevOps and how Platform Engineering is the new cool thing
There is a lot of fuss on the internet about the role of a DevOps, it doesn't take much to find posts such as "There’s no such thing as a “DevOps” engineer", or DevOps is dead, long live Platform Engineering!.
There is plenty of articles on the internet on how DevOps was supposed to be operations delivered by developers, to remove silos between sysadmins and developers and get rid of the idea of "throwing the artifact over the fence" (or at least that's how I understand it!).
But as reality strikes, it's really god damn hard to learn all of it and have enough knowledge to be both excellent developer and excellent systems administrator. And that's when the idea of DevOps as a culture has become sort of dead on arrival.
Let's imagine for a moment a project, maybe it's a startup or maybe it's just an internal project for the organization. This project consists of a website, a database, and mobile applications native to each platform (iOS and Android).
Would you consider hiring for that hypothetical project someone who would you call ... MobileDev? DevDb? MultiDev? Someone who instead of owning just one small part of the project (i.e. backend, frontend or specific native platform) would instead own it all to perhaps enable some sort of productivity boost that because you don't have a communication burden between all the involved parties in the project?
I could call it MultiDev and say this is now our new culture where instead of silosing knowledge to each platform, we now have expectations of everyone to know every part of the platform and know how to deliver for it?
Yeah, I'd not want to be a part of this. Unless you pay ridicolous amount of money for all that knowledge and context switching. It turns out that each platform, or part of the project requires so much specialized knowledge that it's damn hard to have everyone be involved in every part of it. That's why people tend to specialize.
The same I'd say has happened to DevOps philiosophy. At one point it was supposed to remove the silos so that you should own not just your part of the project but also process of delivering it and keeping it working but the part of "just delivering it" or "just keeping it working" is also a specialization in itself that expecting every engineer to know about it is really hard.
Of course in an ideal world I'd love for every developer to know about every other platform and be able to meaningfully contribute to it, it would really speed up the delivery of the projects and save us all a lot of money, stress and miscommunications that arise from everyone specializing in just their own field. But just as you wouldn't expect your car mechanic to build their own car from scratch, you don't expect everyone to know how every piece of technology works down to the level of silicon.
And that brings us to theme of this article - what are all these titles and why would you want to hire anyone for that role?
As I see things, whether you call that role DevOps Engineering, Platform Engineering or Site Reliability Engineering (or perhaps even Systems Engineering?) it all comes down to this: it's a person who makes sure that your foundation for the project you're trying to deliver are all set right so you can focus on delivering what your developers are best at. I'm intentionally being vague here as that role can be totally different in different organizaitons and projects.
If your application is mostly a desktop, offline one, then this person would mostly take care of making sure that you can deliver your installation artifacts to the customers, that they're able to download it from all around the world without a problem and that your process around creating it is optimized so you don't waste time fighting Git flow every time you want to make a change. That person could also consider adding some sort of error reporting so that customers can send errors for your team to investigate. Perhaps it's something that just one of the people in your org could already deliver because it doesn't sound like much work. Or that your IT takes care of it. But if you were to hire DevOps Engineer (they would be bored as hell probably), then that would be what this person could do.
If, however, you're delivering cloud-native, always online web-based app, then this person would probably take care of not just your CI/CD pipelines, but also making sure that you're not wasting money unnecessarily on your Cloud because you're using wrong type of Load Balancers, making sure that the infrastructure within that cloud enables you to do whatever is needed to deliver value to your customers without developers having to worry on how they can deliver their features to the production.
Of course the description here is heavily simplified, there is also day-two operations that are handled by people in roles that are called these days Platform Engineering or Site Relability Engineering but that's topic for another time :)