There are way too many titles in the IT space that essentially all mean the same thing. To cause even more confusion, there’s Platform Engineering. Here’s the thing - there’s actually a good reason for this new title.
In this blog post, you’ll learn all about what Platform Engineering is and the critical differences between Platform Engineering and other popular titles.
SRE vs Platform Engineering
The first jumbled up explanation between Platform Engineering is typically a comparison with SRE and Platform Engineering, both of which are two incredibly different practices.
Site Reliability Engineering (SRE) is all about performance and application/system reliability.
Platform Engineering is all about accelerating software delivery efficiency and velocity.
Do some SRE practices work with Platform Engineering? Absolutely. For example, if the platform you’re creating to ensure software delivery acceleration is down, it’s not much use to anyone. Because of that, you’ll want to ensure uptime with monitoring and observability on that platform, which ties directly into the application/system reliability piece of SRE.
SRE = Performance and reliability.
Platform Engineering = Efficient software delivery.
DevOps vs Platform Engineering
The next comparison you’ll often see is around DevOps and Platform Engineering. Let’s break these down.
First and foremost, DevOps was never meant to be a title or a job position. It was meant to be a practice and a philosophy around software delivery that everyone used. However, over the years, it became a title and unfortunately, it just ended up being cloud engineers or infrastructure engineers that knew how to script. That of course isn’t a bad thing, but it shouldn’t have been a DevOps title. It should’ve been something like “automatic engineer”.
DevOps, outside of the title thing, make a developer have to become an expert in tools that they want to run. This really shouldn't be the case because developers already have core activities and responsibilities. Learning and becoming experts in tools just adds to cognitive load and stress.
Platform Engineering gives developers the tools they want to use, but in a developer platform that’s easily learnable and accessible (at least way easier than learning all of the needed tools).
Breaking Down Platform Engineering
When you think about Platform Engineering, it’ll come down to the following:
- Internal Developer Platform (IDP).
- Making software delivery more efficient.
- Giving developers an effective way to ship software.
- Creating reliable repeatability.
- Automating developer workflows.
Some may say that the above already exists and most would agree, but only to a certain extent.
let’s dive into an example.
There are effective ways to deliver software, like CICD and various “one click to development” platforms both for on-prem, cloud, and Kubernetes-based workloads. The problem is that there’s still someone in the middle doing the work and handing it off or developers still have to learn new tools. Either DevOps engineers have to build pipelines and then work with Dev teams to confirm they work as expected or developers have to learn CICD.
With the example above, we can now see that developers need a way to make their jobs more efficient. They need a way to deliver the software that they need without the holdup or needing to learn various different tools and technologies. They need a way to ship software as reliably as possible while sticking to what they want to be doing, which is writing code.
That’s where Platform Engineering comes into play.
Tldr; Platform Engineering is a list of integrated capabilities that are created according to what the platform user needs (the platform user is the internal engineer/developer using the platform).
Top comments (6)
Great job 👍
This blog post is amazing! Really puts all the different, kind of overlapping titles and practices into a good, digestible perspective.
They need a way to ship software as reliably as possible while sticking to what they want to be doing, which is writing code. This is a good example to understand the concept, but it appears to be incomplete without a real implementation example. Could you provide a very simple one?
Actually developers don't need "to ship software reliably". An endpoint of their responsibility is a source code repository. Yeah, the application represented by its source code should match to some specifications of a building, working environment, data layout and interfaces. To check matching to this specifications, they need an environment that respects production environment as much as possible. Of course they need delivering their updates to the test environment AFAP. And the best for it is an automated delivery. IMHO, that's it.
I wonder if people treat DevOps as "development and operations". For me it's always a development of operations.
It's much wider that just a development and just an operations.
Just for clarification... There is no much sense to put on developers some intentions that actually they don't have.
As I understand it's implied that we always talking about so called "startup development model" where all changes in code are delivered immediately. But it works only for some web services.
I'm real life usually we can have a long time beta testing, or the release should synced with some business/market concerns, and so on...
My main thought here is, everybody should do his job. Some people is responsible on an application, some on infrastructure. An infrastructure is pretty complicated part of a system. And creating and servicing it requires standalone skills.
With the same approach to SRE, it's just a way to estimate quality of a DevOps work from PoV production. It defines respective KPI and ways to handling some concerns. And to be honest nothing more than it.
I have a feeling that Platform is one of the most overused words nowadays. Speaking as a platform engineer who builds... external developer platform that allows to build apps for a service using the API/SDK provided :D
Well done!!!
Some comments have been hidden by the post's author - find out more