The problem is not new: modern software architectures are complex distributed systems composed of many independent services, many of which are built by other teams or cloud providers. Kubernetes wrangles this herd of services – but adds even more complexity that must be tamed. This creates serious problems at the intersection of development and business. Developers are frustrated when they have to manage a series of complex, arcane services and tools in which they are not experts. Operators are frustrated when non-expert developers build infrastructure that is not satisfactory. Developers complain that Ops slows them down. Ops complains that developers are pushing code that isn’t resilient, compatible, or secure.
What is new is the solution: platform engineering. Operational platforms sit between the end user and the supporting services they rely on. The Platform is an in-house software product, built by a dedicated team, that provides a curated collection of reusable components, tools, services and knowledge, packaged for ease of use. As illustrated below, the platform becomes a layer of abstraction between developers and the messy complexity of operations.
The specific components and capabilities of each platform vary greatly. Ultimately, the platform is what the 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:
- Produced: The platform is a product. User feedback guides product strategy.
- User oriented: Platforms solve users’ problems, not operators’. For example, developers probably don’t want a quick way to build a VM; they don’t want to think about infrastructure at all.
- Supermarket: Developers can access everything they need from one source, without opening tickets, sending emails, or submitting requests.
- Consistent and compliant: Standards are built in, so users can’t deliver code that doesn’t conform to specifications or is unsafe.
The platform is a “paved road” that includes both guidelines (recommended ways of travel) and guardrails (hard boundaries that the user cannot cross). The platform could to carry out compliance guardrails: “You must run these automated tests of your security posture before deployment.” However, maybe just propose specific workflows: “We recommend the following tool for these use cases.”
What’s new: Platform engineering delivers on the promise of DevOps
It is important to distinguish platform engineering from what came before. Automation is nothing new; nor calls for better cooperation between developers and operators. The platform goes beyond existing techniques and tools. It’s a new software product, with its own customers, lifecycle, user agreements, and high expectations.
Platform engineering is the pinnacle of DevOps. So it’s not surprising that platform engineering quickly became the hottest topic of conversation in that world, spawning its own user community and conferences. Gartner has named platform engineering as a major strategic technology trend in 2023 and 2024 and predicts that by 2026, 80% of large software engineering organizations will establish teams of platform engineers.
What now: The platform revolution has begun
IT shops have already started implementing platform teams. Most start by building an internal developer portal, often using the Backstage open source project. The portal is a central service catalog and document repository. It can also be a graphical user interface for automation and delivery pipelines. The user experience should be noticeably better than any homebrew solution that developers have built for themselves. The goal is not to force developers to get involved; you should want to use it.
Platforms make developers more productive. They free developers from the burden of building their own work environments. This allows developers to avoid unnecessary “glue” work and focus on writing code that creates value. When measuring the value of a platform—or making the business case for building one—focus on its positive impact on productivity. Implementation rates should increase; error rates, incidents, exceptions, rework, and time-to-value should decrease.
What’s next: Platforms expand and evangelize
Platforms start small, often with just documentation and a catalog of services. But this is also valuable. Saves developers from having to open tickets or send emails. Over time, the platform becomes more capable. In the maximal vision of platform engineering, the platform has its own set of APIs. Developers write on the platform, and its abstractions become the wearable parts of the application.
The platform can also be extended to other users—data scientists, for example, or even business units that want to automate their work. And they will find value in a platform that meets users where they are. A platform team that can provide building blocks that are immediately useful, with appropriate cognitive load, without overly constraining users or forcing them into extraneous ways of working, provides value now and in the future.