Why you should care about platform engineering

You’ve heard about DevOps. You’ve likely heard about SRE. But platform engineering?

Over the past year or so, platform engineering has been trending upwards. From companies offering solutions to help organizations build an internal developer platform, to an uptick in Google searches, there are signals that platform engineering is more than just a social media trend.

But what exactly is it? What are the benefits? And how does it differ from other, more traditional DevOps approaches?

In this post, we’ll provide context on how platform engineering fits into the DevOps landscape. We’ll also provide a brief overview on how Unleash can fit into the picture.

What is platform engineering?

The goal of platform engineering is to empower developers to properly own and operate their services and reduce their cognitive load.

Sounds idealistic, right?

For teams to properly own and operate their services, it suggests an increase to their cognitive load. 

Knowing how to deploy your infrastructure. Performing emergency actions such as rollbacks. Properly managing configuration of your applications. 

This kind of ownership can take a lot of effort. And this is outside of developing the application itself!

In some organizations, a DevOps or SRE team is responsible for handling this cognitive load. While the two types of teams differ, what usually happens is the DevOps or SRE team will assist with operational issues. 

The intention is to reduce operational toil on the application team. This can take many forms, such as implementing automation, or embedding on application teams to spread operational knowledge, for example.

Platform engineering takes a more holistic approach to reduce the burden. It doesn’t force developers to become DevOps experts and learn the tools to handle these types of operational problems. 

Instead, platform engineering teams design an internal developer platform that provides an easy-to-use abstraction on top of those tools. 

This means application teams and developers don’t necessarily need to know all of the intricate details of working with tools like Terraform and Helm, Jenkins or CircleCI. They don’t need to become familiar with containerization solutions like Kubernetes or AWS ECS. 

The platform engineering team aims to provide well-worn implementation paths through their internal developer platform. This means application teams can easily own and operate their services. They’ll also spend their cycles working on the application instead.

The road to golden paths

A more commonly used term for these well-worn paths are ‘golden paths.’ 

With an internal developer platform, a golden path can be leveraged by application teams to get their code from the commit stage into production faster. This is without the overhead of doing all the heavy lifting themselves.

As Jeff Lawson, CEO of Twilio, wrote in his book Ask Your Developer, his company invested heavily in building a platform that could provide a standard pipeline for their engineers. 

An application team could select the golden path for their language of choice. This gave them a build pipeline with artifact repositories, testing frameworks, integrations to their cloud providers, deployment capabilities like blue-green or canary, and rollback functionality. 

This cut down on the cognitive load that would have been placed on the team to perform this operational toil by themselves. Done manually, the process would have been tedious and error-prone.

The internal developer platform is much like the glue that binds all of these concerns together into a consumable package for application teams. 

This is much more desirable than each team potentially reinventing the wheel over and over again. And it means the teams spend a lot less time doing work that doesn’t provide much value to their application and their customers.

Treating the platform as a product

Platforms will likely look different at each organization because the platform is treated as an internal product. 

Like any software, customer feedback is key to shaping it and an internal developer platform is no exception. 

The platform engineering team should adopt this product mindset when building out their platform. They should understand what developers need to make their lives easier.

To elaborate on the Twilio example, the team listened to their engineers. They then supported various languages used by their application teams. 

However, if a team wanted to use a language outside of that support, the team was on their own. They would have to build their own systems to get their code out the door. 

If this new implementation were successful, it could be picked up by the platform engineering team to roll into their existing platform.

To gauge success, platform engineering teams should be driven by developer feedback and metrics. 

They could likely monitor DORA metrics to see if deployment frequency has increased, lead time is faster, and the stability of the overall product is better. 

Another method could be polling the teams with an eNPS survey to get feedback on developer satisfaction.

How can Unleash fit into the picture?

Internal developer platforms are essentially a collection of self-service tools glued together. This means Unleash can be included as part of that platform to help teams with the feature toggling at the deployment stage.

Many internal developer platforms are built on pre-existing solutions like with Spotify’s Backstage. Sometimes they’re built by the platform engineering team themselves. 

This, of course, depends on the maturity of the platform engineering team. The platform could be a command-line interface, or it could have a user interface for developers to interact with via a browser.

Under this model, it’s easy to see how Unleash could be included, as we’re an open-source, API-first solution. This means everything can be automated, which is excellent for integrating with an internal developer platform. 

For example, if your internal developer platform is UI-based, you could have your platform reach out to the Unleash API. It would then embed the switches into the platform itself. That way you can still have your platform be one single entity, and not have Unleash be a separate, standalone tool. 

Feel free to take a look at our code on GitHub if you want to go exploring.

Should we start building a platform?

If you’re a fairly small software organization, it’s probably not imperative that you start building out your platform until you reach 20-30 engineers. 

And if you are already an established software organization with a DevOps/SRE culture, you might want to start thinking of ways you can start to productize your own current offerings to the engineering organization.

Like most problems in software, it’s great to start small, solicit feedback, and build from there. The same goes for whether or not you should adopt a platform engineering practice at your company as well. 

Try to understand what your developers biggest pain points are, and whether that’s because of an unaddressed gap or the current offering isn’t providing what they want. 

If it’s the latter, that might be the impetus to start thinking with the product mindset of a platform engineer and start chipping away at a platform that will make their lives easier.