liveBook · Manning

What you will learn in Effective Platform Engineering

Build self-service interfaces to boost developer experience

by Ajay Chankramath, Nic Cheneweth, Bryan Oliver, Sean Alvarez
Foreword by Kief Morris

Chapter by chapter

Chapter 1: What is platform engineering?

The introduction defines an engineering platform, outlines the platform engineering approach, and explains why it can improve software delivery in organizations of different sizes.

1.1 Platforms are more than just DevOps · 1.1.1 Why should I care about platform engineering? · 1.2 When to use platform engineering principles · 1.2.1 When do these principles not apply? · 1.3 Foundational concepts in platform engineering · 1.3.1 Product delivery model for platforms · 1.3.2 Platform product domains · 1.3.3 Platform engineering principles · 1.4 Platform engineering enablers · 1.4.1 Developer experience · 1.4.2 DevOps · 1.4.3 SRE · 1.4.4 Impact of generative AI in the platform engineering space · 1.5 Let’s get started · 1.6 Summary

What you learn in chapter 1 →

Chapter 2: Software-defined products and architectures

This introduction argues that successful platform products need an organization capable of product delivery, architectures designed to evolve, and software-defined engineering practices.

2.1 Product delivery model · 2.1.1 Technical product ownership · 2.1.2 Customers vs. stakeholders · 2.1.3 Optimize for a product · 2.1.4 The importance of a minimal valuable product and early adopters · 2.2 Software-defined platform · 2.2.1 The platform software delivery lifecycle · 2.2.2 Observability-driven development · 2.3 Evolutionary platform architecture · 2.3.1 Backlog management for incremental design · 2.3.2 Capturing user, stakeholder, and market feedback · 2.3.3 Architectural fitness functions · 2.3.4 Domain-driven platform design · 2.3.5 Evolutionary impact of cloud-native technologies · 2.4 Summary

What you learn in chapter 2 →

Chapter 3: Measuring your way to platform engineering success

The introduction frames platform success as something to measure through its effects on delivery, business value, and developer experience.

3.1 Organizational aspects of platform engineering success · 3.1.1 Changes needed for an organization to prepare for platform engineering · 3.1.2 Prerequisites for the change · 3.1.3 Implementing organizational changes · 3.1.4 Building platforms in organizations · 3.2 Path-to-production and platform value metrics · 3.2.1 How do you identify the scope of your engineering platform? · 3.2.2 Platform value modeling and metrics · 3.3 Cognitive load and mechanical sympathy for developers and platform engineers · 3.3.1 What is cognitive load for developers, and how do we measure it? · 3.3.2 Why reduce cognitive load? · 3.3.3 Techniques for reducing cognitive load · 3.3.4 The need for mechanical sympathy · 3.4 Common platform performance metrics · 3.4.1 Adoption · 3.4.2 Developer sentiment · 3.4.3 Effectiveness · 3.5 Evolving measures · 3.5.1 Cost planning · 3.5.2 Risk assessment · 3.5.3 Mapping measurement to core platform principles · 3.5.4 Mapping measurement to platform engineering domains · 3.6 Summary

What you learn in chapter 3 →

Chapter 4: Governance, compliance, and trust

The introduction argues that platform engineering must change how organizations handle governance and compliance without taking control of CI/CD pipelines away from developers.

4.1 Developer autonomy · 4.1.1 What does it mean to make a development team autonomous? · 4.2 Policy-as-code · 4.2.1 Introduction to policy-as-code using Open Policy Agent · 4.3 Platform-managed trust · 4.3.1 Software supply chain security · 4.3.2 Zero-trust networking · 4.3.3 Separating platform customer identity from cloud infrastructure identity · 4.4 Summary

What you learn in chapter 4 →

Chapter 5: Evolutionary observability

The introduction shows how observability data can help an organization understand performance and value, while illustrating the costs of relying on ad hoc spreadsheets to use that data.

5.1 Why observability matters · 5.1.1 Observability is more than metrics and alerts · 5.1.2 Use cases for observability beyond basic monitoring of applications · 5.1.3 What does good look like? · 5.1.4 Viewing observability through a single pane of glass · 5.2 Observability as a platform service · 5.2.1 The end-user access experience · 5.2.2 Automatic collection of customer data · 5.2.3 Who needs to respond when things need attention? · 5.3 Observability platform as a separate internal product · 5.3.1 Architecture of an observability platform · 5.3.2 Should you build or buy? · 5.3.3 Cross-platform observability · 5.3.4 Strategies to drive adoption · 5.4 Observability of published service-level indicators, service-level objectives, and service-level agreements · 5.4.1 SLOs as code · 5.5 Summary

What you learn in chapter 5 →

Chapter 6: Building a software-defined engineering platform

This introduction explains why Epetech needs an engineering platform before the chapter begins building one.

6.1 Building our own example engineering platform · 6.2 Prerequisites to getting started · 6.2.1 Getting started with the example tools · 6.2.2 Developer tools selection criteria · 6.3 Infrastructure pipeline orchestration practices · 6.3.1 Account-level pipelines · 6.3.2 Control plane-level pipelines · 6.3.3 Namespace-level pipelines · 6.3.4 Choosing an IaC framework · 6.3.5 Test-driven development of infrastructure code · 6.3.6 Static code analysis · 6.3.7 Reusable pipeline code · 6.3.8 Private executors (runners) · 6.4 Cloud administrative identity · 6.4.1 Top-level Domain Account · 6.4.2 Platform product test environments · 6.4.3 Internal customer nonproduction and production environments · 6.4.4 Service accounts and permissions · 6.5 Summary

What you learn in chapter 6 →

Chapter 7: Platform control plane foundations

Introduces self-healing as a foundation for Epetech’s engineering platform and explains why Kubernetes serves as its control plane.

7.1 Cloud account baseline · 7.1.1 Account baseline security scanning · 7.1.2 Account baseline observability · 7.1.3 Hosted zones and delegated domains · 7.2 Transit network layer · 7.2.1 Role-based network structure · 7.3 Customer identity · 7.3.1 Authentication and authorization · 7.3.2 OpenID Connect device-auth-flow and team membership claims · 7.4 Cloud service control plane base · 7.4.1 AWS managed node groups · 7.4.2 Dependencies for AWS-managed EKS services · 7.4.3 AWS managed EKS add-ons · 7.4.4 Integrating an OIDC provider with the control plane base · 7.4.5 Post-Terraform configuration · 7.4.6 Strategy for testing EKS base · 7.5 Summary

What you learn in chapter 7 →

Chapter 8: Control plane services and extensions

The introduction establishes the platform’s current control plane baseline and identifies services and extensions as the cluster-wide components still to be added.

8.1 Value of services and extension domains for smaller teams · 8.2 Value of services and extension domains for scaled platform delivery · 8.2.1 Which services or extensions should be a part of every platform from the start? · 8.3 Control plane services · 8.3.1 Services pipeline orchestration · 8.4 Control plane extensions · 8.4.1 Kubernetes storage classes · 8.4.2 Service mesh · 8.4.3 Using operators for persistent data platform capabilities · 8.5 Platform management APIs · 8.5.1 Managing teams and namespaces for early adopters · 8.6 Summary

What you learn in chapter 8 →

Chapter 9: Architecture changes to support scale

The introduction frames platform scaling as a business-driven architectural and organizational decision, not simply an increase in capacity.

9.1 Scaling the control plane roles · 9.1.1 Dynamic release pipeline · 9.2 Scaling the orchestration of control plane services and extensions · 9.2.1 Scaling the creation of OpenID Connect Assumable Roles · 9.3 Scaling through platform event streaming · 9.3.1 release-api · 9.3.2 Adapter pattern · 9.3.3 Adapter pattern: Issue tracking · 9.3.4 Adapter pattern: CI hooks · 9.3.5 Adapter pattern: Observability hooks · 9.3.6 Adapter pattern: Configuration management database and audit gathering · 9.4 Summary

What you learn in chapter 9 →

Chapter 10: Platform product evolution

Introduces platform product evolution by explaining why a platform strategy matters as organizations and their software ecosystems grow more complex.

10.1 Measuring the success of your platform organization · 10.1.1 The platform value model · 10.1.2 Epetech’s approach to measurement · 10.1.3 Implementing feedback loops · 10.2 Platform-as-a-product as the differentiator · 10.2.1 Defining the platform vision and mission · 10.2.2 Establishing a product roadmap · 10.2.3 Implementing agile practices · 10.2.4 The role of the platform product manager · 10.2.5 Differentiating through user experience · 10.3 Cultural shift from a traditional operations world · 10.3.1 Embracing DevOps cultural principles · 10.3.2 Breaking down silos with team topologies · 10.3.3 Effects on Epetech’s culture · 10.4 Site reliability engineering strategy, models, and aligning with organizational needs · 10.4.1 Understanding SRE · 10.4.2 Implementing SRE at Epetech · 10.4.3 Aligning SRE with organizational goals · 10.4.4 Outcomes of implementing SRE · 10.5 Using intelligent assistants to help enhance engineering platforms · 10.5.1 The role of intelligent assistants · 10.5.2 Epetech’s EpetechBot · 10.5.3 Exploring advanced tools · 10.6 Comparing IDPs and developer portals · 10.6.1 Understanding IDPs · 10.6.2 Understanding developer portals · 10.6.3 Comparing and contrasting IDPs and developer portals · 10.7 Outcomes from building the platform products · 10.7.1 Key takeaways from Epetech’s journey · 10.7.2 Benefits realized by Epetech · 10.8 Summary

What you learn in chapter 10 →

Concepts explained in this book

These guides are generated from the text of Manning books by Manning's knowledge graph and link to the sections they draw on. The full books are available on liveBook and at manning.com.