The rise of platform engineering – the next big thing?
Platform engineering is establishing itself as the answer to the increasing complexity of software provision and the high cognitive load on development teams.
(Image: iX)
- Mirco Hering
The DevOps-driven world of software development is fast-paced; one new tool follows the next and new buzzwords such as DevSecOps or SRE (Site Reliability Engineering) are moving into the spotlight. A frequently discussed question in the DevOps community is what the next big thing will be. Platform engineering is highly touted as the latest potential replacement for DevOps. The latest edition of the online conference PlatformCon attracted thousands of attendees from all over the world.
- With a focus on the productivity and job satisfaction of development teams, Platform Engineering is establishing itself as an alternative to the DevOps toolkit.
- Platform engineering seeks a balance between standardization and flexibility.
- To be successful, platform engineering must follow the principles of product development.
The DevOps community is a pretty open-minded community as there is no manifesto or methodology to define an in-group or out-group. Concepts such as SRE or platform engineering are considered more of an addition to the DevOps toolkit that organizations can use to improve the way applications are deployed and increase the productivity of development teams. Productivity is also a good indicator of job satisfaction (keyword: developer experience). In practice, factors such as the workload and cognitive load of development teams often have a negative impact on productivity.
Platform Engineering stands out from other current trends because it addresses a problem that has only recently come into focus: the increasing complexity of software provision. Platform Engineering addresses this challenge with the aim of improving productivity and job satisfaction for teams. This comprehensive approach also explains why platform engineering has gained popularity so quickly.
Is platform engineering the next DevOps?
So is platform engineering the new DevOps? Probably not. DevOps has provided the IT community with a wealth of tools and principles that are constantly being improved and expanded. DevOps is characterized by a strong cultural dimension: "Blameless Post-Mortems" (retrospectives without assigning blame), for example, focus on avoiding burn-outs and breaking down organizational silos. These are holistic organizational concerns, whereas many of the trendier concepts focus on one specific dimension at a time: DevSecOps focuses on security, SRE on modern operating models. Platform engineering aims to technically enable teams to cope with increasing complexity. Platform engineering is therefore more of a new way of looking at DevOps. It extends the focus to the developer community and business interests such as security and infrastructure operations.
Countering increasing complexity
What makes the provision of applications and IT infrastructure so complex today? Around 15 years ago, quarterly software releases were common and developers had to provide a few dozen systems for each release - mainly monolithic individual software and software packages. The go-live was usually preceded by a strict code freeze period lasting several weeks. A printed project plan including an inventory of all required elements and their versions was available in a "war room".
Since then, the situation has changed significantly due to the emergence of cloud (native) technologies (see Figure 1). Including services from cloud providers is easier. But the growing share of open source software has led to hundreds of open source elements being included in a software release, with many transitive dependencies that multiply the elements included in the source code. The typical release cycle is no longer quarterly, but rather monthly, weekly or even in much shorter periods. The associated tasks increase complexity, as does the rapidly growing number of tools. While much of the work used to be done manually, nowadays dozens of tools are involved in a release cycle - including in the areas of testing, builds, releases and infrastructure. The practice of DevOps and agile methods of leaving the choice of tools to the teams has also led to a strong diversification of tools, especially in larger companies - and thus contributed to even more complexity.
(Image: Mirco Hering / Accenture)
While in the days of war room releases, individual responsible persons were still able to gain a complete understanding of the software to be provided, this is hardly possible today given the multitude of processes and tools and the ever shorter release cycles. However, the increased complexity is not fundamentally a bad thing. Rather, it is a consequence or a side effect of the significantly more comprehensive deployment capabilities in software development. However, platform engineering offers suitable means of effectively countering the threat of loss of control and rising costs and risks due to excessive complexity.
Platform engineering counters complexity with a standardized framework and common templates. This is more difficult than it sounds, as many failed implementations of a standardized tooling platform according to the motto "one size fits all" have shown. Especially in large, heterogeneous organizations, it is often difficult to find the right balance between standardization and flexibility when it comes to reconciling a variety of technologies for all stakeholders.
To provide developers with a variety of options to find answers to their most common security, infrastructure or application deployment problems, platform engineering includes comprehensive documentation and a variety of patterns. In addition, compliance with company standards should be simple. Development teams must also have the flexibility to experiment with new tools and practices. This includes, in particular, new services and functions from cloud providers for software engineering. Platform engineering must strike the right balance and provide the necessary governance for the constant pendulum swinging between expansion through experimentation and subsequent consolidation. This is the only way to find a resilient operating model for the developer platform. The architecture of the platform should be based on the architecture of business applications (see Figure 2). To this end, the entire software development lifecycle should be based on an integrated platform that is only loosely coupled. Among other things, this ensures the freedom to replace components when it appears necessary - for example, when a new, better tool is available for a specific task. The loose coupling makes it easier for experienced teams to make changes themselves and contribute to the platform.
(Image: Mirco Hering / Accenture)
It is advisable to align platform engineering with the principles of product development with a focus on the internal development teams. This also includes external developers, if available. The scope and approach of platform engineering are geared towards empathizing with the requirements of the users/customers and thus increasing the acceptance of the platform. However, the platform stakeholders remain the guardians of processes and standards such as security and infrastructure. The platform development team must therefore mediate between the various interest groups in order to create a practicable solution for all parties involved.
