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).