Think of the typical User Interfaces (UI) you log into.
These are all platforms that you can use to perform a particular task. That’s how platforms have been defined for years. Going a step further, VMWare ESXi environments have been thought of, called, and referenced as platforms.
A platform is a location that you access via a UI or a programmatic method (CLI, Operator, API, etc.) to perform a particular action in an abstracted fashion.
Think about if you didn’t have a platform. Take Reddit as an example. If you didn’t have the interface, you’d have to gain access to a Reddit server, find the database where the particular subreddit exists that you want to post to, enter a database entry, and then send that database location (theoretically… stick with me) to all of the people you want to comment on it.
It would be pure madness.
With that, what can platforms be?
When thinking about a platform before Platform Engineering, it could be anything from a UI to a hypervisor to a little utility that makes the lives of engineers easier.
For example, let’s take a common example. Pretend that you work at a startup. You’re the only DevOps/Platform/Cloud (whatever other title you want) Engineer in
the company. You’re doing all of the AWS things and the Terraform things and you’re the expert in this area. You then find out that the majority of the technical part of the organization, although very good engineers and very technical, are primarily in software engineering. Because of that, they don’t know the cloud or Infrastructure-as Code (IaC) like you do. They know they have to use it, but they don’t know it. What you can do in that case is maybe build them a command-line tool that gives them a few subcommands for the services they use in the cloud for creating, updating, and deleting. That way, they can work with the cloud without working with the cloud.
The gist is that we were doing Platform Engineering before Platform Engineering was Platform Engineering (say that 10x fast).
Now, engineers are seeing platforms a bit differently. The idea of the CLI story/example above is still valid, but engineering a platform is thought of with a slightly different approach. It of course always depends on who you ask, but one thing is for sure - what platforms were considered “then” vs “now” is drastically changing.
Platform Engineering right now is all about:
Platforms should be one thing - whatever the internal engineer/developer needs it to be. That’s it.
A proper platform isn’t about what you want to build. It isn’t about what features and capabilities you want it to have. Every bit of a platform that you build as a Platform Engineer is all about what the internal engineer/developer wants. Now, of course, there are contingencies there. If they ask you to build a platform that creates real-life unicorns, you’ll have to politely let them know that isn’t possible. If they ask you to build a UI and you build them a CLI, you need to go back and redo the platform.
💡 You’ll hear a lot that Platform Engineering is about building Internal Developer Platforms (IDP) and when engineers hear that, they think Platform Engineering is all about the Developer. This isn’t the case at all. Platforms can be built for any engineer from IT Helpdesk to QA to Cyber Security and everyone in between.
No Platform Engineering post makes much sense right now without at least a slight mention of Internal Developer Platforms (IDP).
The gist of an IDP is a pure UI layer that has all of the capabilities an internal engineer/developer needs it to have but in an abstract fashion. For example, if they know they need GitOps, you can add ArgoCD, Flux, or whatever other GitOps Controller you want. They don’t need a specific one. They just know that they need to “do the GitOps thing”, so you build that solution for them.
An IDP gives just enough abstraction for engineers to do their job in an easy way.
Platform Engineering is a mess. It's been taken over by buzz, lots of external marketing, and overall hype about what it's assumed to be.
Make it simple for yourself.
Platform Engineering is three things:
Yes, the engineering ability is a given, so it doesn't need to be listed. It's table stakes.
The goal of a Platform Engineer is to build a platform that other engineers can use to make their lives easier. That’s it, plain and simple.
To do that, you need the ability to understand what the engineers want out of a platform (customer service mindset) and create a plan to build it effectively (product management mindset) in a way that’s efficient, productive, and necessary.