In this blog post, you will learn what Platform Engineering is and how it works within organizations ranging from startups to enterprises.

Why The New Title

‍

As iterations of the technological landscape continue, positions and job duties will be refined. A relatively new refinement that has occurred is Platform Engineering. The goal with Platform Engineering is to focus on the following:

1. Engineering with a product mindset
2. Internal user support
3. Customer service for internal users

As a whole, a Platform Engineer is responsible for building tools within an organization and not necessarily for external use. It’s a position that helps support the needs of internal engineers and developers that are potentially working on products that are, in fact, externally used.

In short, Platform Engineering is a way to minimize the cognitive load of internal engineers and developers.

‍DevOps vs Platform Engineering

‍When it comes to new titles and responsibilities, the majority of organizations tend to try to compare them with something theyʼre already familiar with. One of those comparisons is DevOps to Platform Engineering and it’s a comparison you’ll often see. 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 who knew how to script. That of course isnʼt a bad thing, it just requires a change in mindset from the original purpose.

DevOps, outside of the title thing, requires a developer to become an expert in the 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).

‍SRE vs Platform Engineering

‍The second of the two positions that unfortunately get thrown into the same box is Platform Engineering and SRE, 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.

‍Key Aspects of Platform Engineering

‍Now that you know a bit about Platform Engineering, itʼs purpose, and how itʼs not like DevOps/SRE, letʼs spend the rest of the blog post talking about the key components of Platform Engineering from a technology and implementation perspective.

💡 Although youʼll absolutely see things like CICD, automation, coding, and monitoring/observability within Platform Engineering, those things are almost considered “by defaultˮ, which is why they arenʼt directly called out. Think of the general DevOps/SRE knowledge for Platform Engineers as table stakes.

IDP

An Internal Developer Platform (IDP) is what your internal developers and engineers use to interact with the platform you created for them. Whether itʼs a GUI, a CLI, an API, or whatever other type of interaction they want or need. By definition, an IDP is built by a platform team to build golden paths and enable developer self-service. It consists of various tools put together in a way that lowers cognitive load and abstracts away complexities. Essentially, it’s a method of using tools that the developers/engineers may not know how to use, but can use with abstractions built on top.

Customer Service

Customer Service is key to Platform Engineering. Remember, the job is to create efficient processes for internal platforms and systems, reduce cognitive load, and ensure separation of concern. A lot of that will come from what engineers and developers internally need, which means Platform Engineers are going to be doing a lot of talking, planning, and working with others to ensure what they need is done. Just like when someone calls a customer service rep for a product you have or an order you’re waiting for. Itʼs their job to get you to the end state that you’re hoping for and do it in a pleasant manner.

Product Mindset

A product mindset is a bit different than an engineering mindset. Sometimes, you'll find engineers just tasked with something and they run with it. Not necessarily thinking about everything else as a whole, but figuring out the particular way to fix or implement the task they're assigned. A product mindset is a bit different. You're looking at everything both holistically and from an engineering perspective. Youʼre thinking about:

SLAʼs

Customer happiness

Implementations that customers want

Specific features to drive productivity

A customer service and product mindset is key to proper Platform Engineering.

Closing Thoughts

All engineering disciplines in the cloud-native world end up getting woven together in some way, shape, or form. DevOps teams use monitoring and observability. SRE teams use pipelines. Cloud teams use programming languages for automation. The goal here is to split some of the workload between engineering teams, and the workload split for Platform Engineering teams is ensuring that the internal engineers/developers have what they need to be successful.

‍