What is platform engineering, and should my business adopt it?

Most developers hate doing anything that’s not coding: managing infrastructure, creating and configuring repositories, handling CI/CD pipelines, and so on. Most of the time, they wish they could just focus on what they’re good at — writing awesome code — and let someone else handle the rest. 

Well, guess what? There's a solution for that: it's called platform engineering. It’s a way to cut down on the burden of work on developers, so they can focus on delivering value to production. It’s also a way to avoid some of the common pitfalls of implementing DevOps.

Platform engineering is the process of building toolchains and workflows that empower developers with self-service capabilities. This enables them to independently handle the entire software development life cycle. Together, these toolchains and workflows are referred to as a platform, with the Internal Developer Platform (IDP) at the core. 

To put it simply, an IDP is made up of the technology and tools a developer needs to do their job. All the setup is abstracted away according to the needs of the individual developer. The task of creating and managing these platforms is typically handled by a platform engineering team, who treat the developers as internal customers and the platform as product delivery.

Right now, platform engineering is gaining a lot of buzz as an emerging field. Cloud providers like AWS and Azure are building services just to support platform engineering. Meanwhile, companies like Accenture are offering platform engineering as a service. It’s becoming very popular, very fast.

The roots of platform engineering really start with the rise of DevOps. Fifteen years ago, DevOps really took off: organizations began adopting it, tech professionals and developers embraced it, and new tooling for DevOps popped up. It was the golden approach which would break down silos between ops and developers, and empower organizations to ship software and solutions faster. Who wouldn’t want that?

And for many organizations, DevOps delivered on this promise. However, numerous others struggled to achieve desired outcomes, and their DevOps initiatives failed. 

Why? There are various ‘anti-patterns’ (also known as ‘anti-types’) that undermine the effectiveness of DevOps projects. An anti-pattern is a common response to a recurring process that winds up being highly counterproductive.

One of the primary anti-patterns for DevOps — and a common reason for the failure of DevOp projects — is a lack of cohesion. A small team within the organization (often developers) is burdened with building their own structures and workflows to implement and operate DevOps. This team assumes the responsibility of assembling the required tools and workflows to effectively manage development and operations tasks, effectively becoming the focal point for transforming the abstract concept of DevOps into a functional framework.

The result? Unsuccessful DevOps rollouts or decreased efficiency, resulting in slower software or solution delivery. This is the exact opposite of what you want from implementing DevOps.

For a comprehensive list of common DevOps antipatterns, you can refer to the following resource: DevOps anti-types.

If you are familiar with the concept in ITIL called a service catalog, then you will understand the concept of Internal Developer Platforms. Both ITIL's service catalog and an IDP in Platform Engineering serve as centralized resources to facilitate service provisioning and management within an organization. 

• The ITIL service catalog provides a structured overview of available IT services, their descriptions, and associated service-level agreements. 

• Similarly, an IDP, such as Backstage or Humanitec, acts as a catalog for developers, offering a self-service portal to access tools, services, and resources needed for software development.

• Both provide visibility into available offerings, promote standardization, and enable teams to easily discover and utilize the services they require. 

Ultimately, both the ITIL service catalog and the IDP aim to enhance efficiency, collaboration, and transparency within their respective domains.

A common misconception about DevOps is that it’s all about tools, and since platform engineering deals with tools, you might think that platform engineering is a replacement for DevOps. In reality, they are two different things.

Think of platform engineering as a way to enhance and centralize much of the DevOps tooling already being utilized. Platform engineering helps organizations realize the benefits of DevOps by solving the infrastructure gaps that can stop it being successful. 

For more on this topic, read this article: “Platform Engineering: A DevOps evolution, not a replacement.”

Platform Engineering streamlines the DevOps toolchain and workflows by bundling these into a concept known as golden paths. A golden path can be thought of as a set of tools and workflows that would fit a common need of a developer. A golden path makes it easy for a developer to shop for what they need and move forward, without having to reinvent the wheel for a software project.

You should treat platform engineering as an internal product, and your development teams as your customers. You should apply product management principles to the IDPs development and evolution. This means:

• Understanding the needs and requirements of the platform's users, whether they are internal developers or other stakeholders. 

• Gathering feedback, conducting user research, and prioritizing features and improvements based on their value and impact.

• Taking a holistic view of the platform's lifecycle, from initial design and development to ongoing maintenance and iteration. 

This mindset ensures that the platform is treated as an evolving product, with a clear vision, roadmap, and dedicated focus on delivering value to its users.

As a rule of thumb, if you have 20 or more developers, it’s a good time to consider adopting platform engineering. Most of the tools involved are common and you may already know them if you have been working in DevOps or GitOps. This means it’s a small learning curve to expand into platform engineering.

Even if your organization is not currently ready, it is an emerging space that you should not ignore. The need for platform engineering has existed for some time, and the problem it solves for DevOps isn’t going away.

• Explore whether there is a need or not on the horizon for Platform Engineering and prepare for it.

• Consider running a platform engineering pilot project that can be iterated on.

• Continue to educate yourself through blog posts on platform engineering (like this one) and books as they become available.

• Participate in user groups, conferences, and slack communities — you can find these at www.platformengineering.org.

• Last but not least, do some training on Platform Engineering!

To delve deeper into the topic, check out my course: "Platform Engineering: The Big Picture." This course provides you with the skills and knowledge of platform engineering needed to take the next steps with it. You can access this course on Pluralsight with a 10-day free trial. Thanks for reading!