Körbächer, Max / Grabner, Andreas / Lipsig, Hilliary Platform Engineering for Architects

Crafting modern platforms as a product
1. Auflage 2025
ISBN: 978-1-83620-358-2
Verlag: De Gruyter
Format: EPUB
Kopierschutz: 0 - No protection

E-Book, Englisch, 376 Seiten

As technology evolves, IT talent shortages and system complexity make it essential to have structured guidance for building scalable, user-focused platforms. This book provides platform engineers and architects with practical strategies to develop internal development platforms that enhance software delivery and operations.
You'll learn how to identify end users, understand their needs, and define platform goals with a focus on self-service solutions for cloud-native environments. Using real-world examples, the book demonstrates how to build platforms within and for the cloud, leveraging Kubernetes. It also explores the benefits of a product-centric approach to platform engineering, emphasizing early end-user involvement and flexible design principles that adapt to future requirements.
Additionally, the book covers techniques for maintaining a sustainable platform while minimizing technical debt. By the end, you'll have the knowledge to design, define, and implement platform capabilities that align with your organization's goals.

Autoren/Hrsg.

Körbächer, Max, Max Körbächer

Grabner, Andreas, Andreas Grabner

Lipsig, Hilliary, Hilliary Lipsig

Fachgebiete

• Mathematik | Informatik EDV | Informatik Programmierung | Softwareentwicklung Software Engineering

Leseproben

1

Platform Engineering and the Art of Crafting Platforms

In this first chapter, we will learn how to identify when our organization is in the right state to plan a platform. For this, we will clarify why platforms have become such a relevant topic, how a product mindset fits into this, and what the checkpoints are to find out whether we are ready for a platform or not. We will learn about the platform differences and which platform types are most commonly built.

Next, we will delve into the three core elements of a platform: the pervasive cloud, the developer experience, and the main attributes of a platform. Overall, we will see recurring elements of cloud-native engineering. This leads us to the question of whether we really need yet another abstraction layer. We will also consider whether a platform will help us to overcome the problem of a high cognitive load caused by overengineered complex systems and development processes or just end up being yet another layer. We will reflect on some of those layers to find an answer for ourselves.

Finally, we will go into aspects that go beyond the technology and the implementation of platforms. It is crucial to understand the sociotechnical aspects and put the human, our actual stakeholders, at the center. This allows us to define a better platform product and find approaches for a close collaboration.

In this chapter, we’re going to cover the following main topics:

• The demand for platforms as a product
• Implementing developer- and product-focused solutions
• Do we need yet another abstraction layer?
• Sociotechnical aspects

The demand for platforms as a product

In the cloud-native environment, hardly any other topic has built up such a myth in recent years as the term and the associated role of the platform engineer. As with the introduction of the first usable CI/CD pipelines, this gold rush led to rapid adaptation, often without sense or reason. Now that we have arrived in the valley of knowledge, we can deal extensively with the question: do you need a platform, and if so, how do you design and implement it to ensure that it lasts into the future?

To answer this question, we should first look at what constitutes such a platform. A platform is the combination of different capabilities that are required to master traditional and cloud-native environments so that it supports the end user in the development, delivery, and operation of an application. Platforms can be an enabler to turn non-cloud native infrastructures into valuable resources. However, most computing platforms today provide some sort of API that can be used to automate the deployment and instrumentation of the available resources and build the foundation of a platform. Platforms provide consistency across any kind of resources for the end users and grant access to its capabilities via a self-service API, templates, CLI, or other solutions. The following example also highlights that a platform is composed of many components:

Figure 1.1: Example of a platform/IDP

We see usually the topic of platform appears in the context of cloud-native, but why is that so? Cloud-native technologies enable organizations to build and run scalable applications in public, private, and hybrid clouds. This approach is best illustrated by functionalities such as containers, standardized service provisioning, immutable infrastructure, and declarative APIs. Such functionalities realize loosely coupled systems that are resilient, manageable, and observable. These enable developers to make frequent changes with minimal effort. In short, a platform is an enabler for cloud-native computing and uses its tooling to instrumentalize it.

Companies and developers benefit from platforms in an equal manner

The experience of a software engineer on a cloud-native platform differs from developing software natively toward a cloud provider. Building systems focusing on one Cloud Service Provider (CSP) will bind you to the logic of that closed ecosystem. You will surely have a similar effect when you build on cloud-native platforms due to the fact that those are often Kubernetes-centric, utilizing the heavy unification of integrations toward the Kubernetes API. However, the catch is that cloud-native platforms deliver the same experience without you recognizing the underlying infrastructure. As most companies have at least two to three cloud or cloud-like service providers and already have difficulties in adapting those, a cloud-native platform is a game changer . Developing software on a cloud-native platform changes the mindset and architecture. However, without adopting that mindset, the chance of failure is high.

However, there are more aspects to consider for a platform than just unified infrastructure management. Platforms have to be made for a purpose. The common definition of whom platforms are built for, and who the stakeholders for platform engineers are, states that those are exclusively developers. These definitions fall short of mentioning that a whole organization, operational teams, and other specialist teams also benefit from a platform. A platform provides software engineers with a simple access point to build, test, deploy, release, and operate their software. It provides deep insights into the usage and allows the caretaker and administrators to maintain the infrastructure, platform, and integrations fearlessly. To translate this into business terminology, a platform can provide a faster time to market, with more flexibility to change and adjust its components, while keeping reliability and robustness high.

What does this mean for a company now? Due to the shortage of IT professionals on the market, the fast pace of changes in IT, and the overload of training teams for cloud technologies and providers, a platform introduces the right breakpoints for competencies. We need these breakpoints to declutter the trend of putting multiple disciplines into a single role such as DevOps. Also, platform engineers utilizing DevOps methodologies are not DevOps. We actively need to protect this role from repeating the mistakes made with the DevOps role and stay sharp in its definition. Platform engineers integrate experts’ provided capabilities, simplify their usage of those capabilities through their platform for developers, and enable self-service for the engineers. However, no developer will need to become an expert in multiple topics such as security, observability, infrastructure configuration and automation, and so on. This is in contrast to a common picture of DevOps, who need to become experts with anything that is required within their silo for their application to keep them alive. We will need DevOps in the future for the advanced handling of applications, but we must make their lives easier, too.

The platform provides an integration layer for the bottom-up capabilities that require special knowledge such as security, databases, or even the deployment of VMs or bare-metal servers, as well as top-down usage by developers and DevOps. As visualized in the following figure, the platform engineering team is responsible for providing this layer.

Figure 1.2: Capabilities and responsibilities in a platform-driven organization

Of course, this also means that another team of experts must be trained and educated. However, a comparably small team of platform engineers can usually build and run huge environments. A platform ideally reduces the cognitive load for any other team within the company and lets them focus on their core value again by simplifying the machinery around the development process. This platform helps to reduce the stress and improve transparency. Companies from all over the world frequently share their experience with platforms and platform teams, and the typical tenor is on how they solved problems they couldn’t tackle before, or how much this has improved the quality of their products and services.

These platforms are often called Internal Developer Platforms (IDPs) because they are usually built for an enterprise’s internal development team. Throughout this book, we will use the terms platform, IDP, platform product, and cloud-native platform interchangeably. However, we’ll first highlight certain aspects just a little bit more:

• Platform: General term for the cross-cutting layer of technology that allows unification of services for developers.
• IDP: Emphasizing the aspect of developer, Software Development Life Cycle (SDLC), and tools needed to develop software
• Platform product or platform as a product: Highlighting the dedicated team taking care of the evolution ability and long-term commitment of a platform, as well as establishing a different mindset
• Cloud-native platform: Focusing on the abstraction and enablement to use standardized APIs and integrations

That perspective might feel fine-grained, but the term platform itself often leads to more confusion. A cloud platform is also a platform,...

Über Autor(innen)

Körbächer Max :

Max Körbächer is a technology advisor and platform architect who focuses on utilizing cloud-native technologies and open source to simplify the challenges of complex systems. He is the founder and managing director of Liquid Reply, a cloud-native engineering and consulting company. His work history includes roles as an enterprise architect in the media and power utility industry and as a demand manager planning medium and large IT projects. Max is also the founder and, currently, co-chair of the CNCF Environmental Sustainability Technical Advisory Group, CNCF Ambassador, Linux Foundation Europe Advisory Board member, and initiator and organizer of the Kubernetes Community Days Munich and Ukraine.Grabner Andreas :

Andreas Grabner is a technical advocate for making distributed systems observable and making automated data-driven decisions across the software development lifecycle. In his capacity as a CNCF ambassador and a DevRel at Dynatrace, he connects and educates global software engineering communities on building and continuously validating digital services for resiliency, high availability, and security. Since his early days, he has been passionate about software quality and performance engineering as it results in building excellent digital products. Andi uses his advocacy platforms to share best practices on topics such as observability, progressive delivery, DevOps, site reliability engineering, platform engineering, and digital business operations!Lipsig Hilliary :

Hilliary Lipsig is an autodidact and start-up veteran who has frequently learned and applied technologies to get a job done. She's had her hand in every part of the application delivery process, honing her skills originally as a quality engineer. Hilliary is an IT polyglot, able to talk the lingo of both the Operations and Development teams. She's currently a Principal Site Reliability Engineer at Red Hat Inc., working on Kubernetes-based platforms. She's passionate about GitOps, continuous integration, scalable processes, consistency in tooling, and good developer documentation. Her open source activities include contributions to the CNCF Glossary and she's a member of the Code of Conduct Committee for Kubernetes.