Platform Engineering:
Why, What, and How

What is Platform Engineering?

​

Platform engineering is the practice of designing, building, managing, and maintaining platforms for cloud-native software engineering organisations. Platform engineering involves creating and continually optimising toolchains and workflows that serve the operational needs of both application development and developer productivity. 

The usual platform “product” is an integrated, self-service internal developer platform (IDP), which should include everything required for the development, deployment and operation of an application. The overriding purposes of platform engineering are:

• Go faster: Increasing speed (for developers and to market) for applications. Develop everything as a service. This also includes boosting developer productivity.

• Decrease risk: Create safety by incorporating your key processes and automating manual processes.

• Increase efficiency: Scale up by managing your platform as a fleet.

Platform engineering as a discipline exists to support efficiencies in cloud-native software development and self-service capabilities that give developers what they need to do their work at the same time as reducing their cognitive load. 

Why Platform Engineering? 

Platform engineering provides a way to identify development teams’ challenges and create a framework, or platform, on which organisations can build and deliver standardised approaches, common or best practices, and reusable workflows and tools for software development and deployment. The result is an internal developer platform that centralises the developer experience and shields the developer from the overall complexity of developing cloud-native applications.

How has cloud-native complexity influenced the rise of platform engineering?

Cloud-native development and technologies like Kubernetes and microservices have been widely adopted in small businesses and enterprises alike thanks to the promise of faster development, faster feedback loops for developers, faster rollout of software solutions and features and better quality applications for end users. 

However, with the move to cloud native, complexities have emerged along with an expectation that developers should be responsible for coding, shipping and running their own applications, and the line between development and operations blurred. This put an increasing DevOps burden onto developers, at the same time as managing operations in a distributed multi-cloud environment became more convoluted and opaque. Development in this new paradigm has introduced new realities, such as architectural and infrastructural complexity, including API gateways, service meshes, networking and all manner of different tools. Just deploying a relatively simple code change, for example, has become a challenge requiring a deeper end-to-end operational understanding. 

More than that, demanding a level of DevOps code-ship-run expertise from developers has diverted developer focus away from their core development work, diminishing value to the organisation, while also creating developer cognitive overload. For many organisations, asking developers to work this way is unrealistic and negates the benefits of the cloud-native promise – namely more frequent deployment frequency and faster application delivery. 

Who builds self-service internal developer platforms?

Platform teams come into the picture here, aiming to consolidate what can be called “an opinionated set of practices and tools” into a single platform. Internal platforms that result from these efforts are then made or broken by how well platform development is supported within organisations, how well platform teams synthesise the input of internal platform users in building it, and how effectively development processes and operational necessitates are represented in the platform. 

Successful platform teams also act as product teams in that they focus on the ongoing development, improvement and evolution of the internal platform to ensure that it continues to meet changing needs. The more focused an organisation can be on who does what in the IDP space, the faster and greater the potential for getting value from the IDP. In the influential book Team Topologies, there are four team types described: stream-aligned (application teams), enabling teams, complicated subsystem teams and platform teams. And for a platform to be successful and useful, each of these team types may have a role to play. No one individual or team should or can do everything. 

Sharing the load, relieving stream-aligned teams of doing too much DIY work, and taking away some of the groundwork and maintenance from platform teams, makes a difference and requires understanding different team types and asking who else in the organisation can contribute value to the platform? That means, not only do platform engineers do the heavy lifting – but also site reliability engineers (SREs), DevOps engineers getting hands-on with the platform, with significant contributions from other enabling teams, like security engineers, product managers and so on. Extending the “who builds what” equation to include more teams distributes the work more equitably and ultimately lends itself to a more robust platform. This “multiplayer” approach means that the platform ends up more effectively “glued together” to become the golden paths developers rely on.

Platform Engineering Helps Pave Golden Paths 

Even if there is no one-size-fits-all platform, platform engineering as a discipline is about creating a unified experience or “paving a golden path” for developers. Even if there are no restrictions on developers selecting tools and workflows that diverge from a developer platform’s prescribed path, platform engineering is designed to create clearly marked, paved paths in the form of a self-service platform that any developer can use without having to understand the entire ecosystem behind the scenes. 

Adopting a Platform-as-a-Product Approach 

Taking the paved path a step further, treating a platform as a product (PaaP) is an approach that ensures that platforms do not become static or obsolete. Because they are treated as products, they continue to evolve with use and with input from users like developers and operations teams. 
 
Adopting a platform-as-product approach changes more than just the tools a team uses. It is a cultural shift to a product mindset as well as a solution to business demands, aligning in its evolution with the evolution of long-term business goals. 

What Components Should Be Included In a Developer Platform?

There is no single way to get to the “right” developer platform nor a universal set of components that a developer platform should include. To make platform engineering – and the platform itself – successful and accessible to a development team, it’s important for the organisation to know what they need to achieve, for whom they are building the platform, and to consult the platform’s users and stakeholders to understand what the platform actually needs to do to ease the developer journey and improve and speed up the launch of products. The pressure to deliver value to customers faster, safer and more scalably than ever before makes the need to get the platform right more important than ever. 

What might that look like? Typically, IDPs might include some combination of infrastructure as code (IaC), CI/CD pipelines, self-service interfaces, container orchestration, monitoring and observability, service discovery and networking and more. But to visualise an IDP, it might be helpful to picture a layer cake. 

Three layers –  applications, platform orchestration and infrastructure – are essential as the basics for an IDP. The application and infrastructure layers are often the focus when starting out building an IDP. The top application choreography layer is the specialist domain of developers - focusing on the UI, CLI or UX that give developers what they need to code, ship and run their applications. And the bottom layer is the domain of infrastructure engineers, where they can plan, build, and maintain the required resources across various environments and hosting targets.

But undue focus on these two layers leaves out the middle layer: the platform itself. The platform orchestration layer is composed of reusable components, tools, platform services, and knowledge that the platform team manages. This layer gives platform engineers a way to design, enable and optimise all the parts of the platform to reduce technical sprawl and apply processes, policies and workflows consistently. ​

​​