The problem is not new: Modern software architectures are complex distributed systems made up of many independent services, many of which are built by other teams or cloud providers. Kubernetes wrangles this herd of services—but adds yet more complexity that must be tamed. This creates hard problems at the intersection of development and operations. Developers are frustrated when they need to operate an array of complex, arcane services and tools, in which they aren’t experts. Operators are frustrated when non-expert developers build subpar infrastructure. Devs complain that Ops slows them down. Ops complains that Devs push code that is not resilient, compliant, or secure.
What is new is the solution: platform engineering. Operating platforms sit between the end user and the backing services on which they rely. The platform is an internal software product, built by a dedicated team, that provides a curated collection of reusable components, tools, services, and knowledge, packaged for easy consumption. As illustrated below, the platform becomes a layer of abstraction between the developer and the messy complexities of operations.
The specific components and capabilities of each platform vary widely. Ultimately, the platform is whatever a development team needs it to be. The platform team’s job is to build that product. Each platform may be unique, but all platforms are:
- Productized: The platform is a product. User feedback directs product strategy.
- User-centric: Platforms solve users’ problems, not operators’. For example, developers probably don’t want a fast way to build a VM; they don’t want to think about infrastructure at all.
- Self-service: Developers can access everything they need from a single source, without opening tickets, sending emails, or filing requests.
- Consistent and compliant: Standards are built in, so that users cannot deliver code that is out-of-spec or insecure.
The platform is a “paved road” including both guidelines (recommended ways of travelling) and guardrails (hard boundaries the user can’t cross). A platform might enforce compliance guardrails: “You must run these automated tests of your security posture before deploying.” However, it might only suggest certain workflows: “We recommend the following tool for these use cases.”
What’s New: Platform Engineering Fulfills the Promises of DevOps
It’s important to distinguish platform engineering from what has come before. Automation is nothing new; nor are calls for better collaboration between developers and operators. A platform goes beyond existing techniques and tools. It is a new software product, with its own customers, lifecycle, user contracts, and lofty expectations.
Platform engineering represents the state of the art in DevOps. Not surprisingly, therefore, platform engineering has quickly become the hottest topic of conversation in that world, spawning its own user community and conferences. Gartner named platform engineering a Top Strategic Technology Trend in both 2023 and 2024 and predicts that, by 2026, 80% of large software engineering organizations will establish platform engineering teams.
What’s Now: The Platform Revolution Has Begun
IT shops have already begun to implement platform teams. Most start by building an internal developer portal, often using the open-source project Backstage. The portal is a central service catalog and document repository. It can also be a graphical user interface for automations and delivery pipelines. The user experience should be markedly better than whatever homebrew solutions developers have built for themselves. The goal is not to force developers onboard; they should want to use it.
Platforms make developers more productive. They free developers from the burden of building out their own operating environments. This allows developers to avoid unnecessary “glue” work and focus on writing code that creates value. When measuring the value of the platform—or making a business case to build one—focus on its positive impact on productivity. Deployment rates should increase; error rates, incidents, exceptions, rework, and time-to-value should all decrease.
What’s Next: Platforms Expand and Evangelize
Platforms start small, often with only documentation and a service catalog. But even this is valuable. It saves developers from having to open tickets or send emails. Over time, the platform grows more capable. In the maximal vision of platform engineering, the platform has its own set of APIs. Developers write to the platform, and its abstractions become load-bearing parts of the application.
The platform can also expand to other users—data scientists, for example, or even business units looking to automate their work. They too will find value in a platform that meets users where they are. A platform team that can provide building blocks that are immediately useful, at an appropriate cognitive load, without unduly constraining users or forcing them into foreign ways of working, provides value now and in the future.