Chapter 1: What is platform engineering?

Introduction

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

• Shared engineering platform: Describe an engineering platform as a shared system that brings infrastructure, governance, and operational technologies together for internal development teams.
  Why it matters: This definition gives the reader a starting point for distinguishing a platform from a collection of unrelated tools.
• Platform engineering approach: Explain how dedicated teams create a shared platform that lets developers access capabilities directly, work independently, and meet embedded governance requirements while tracking measurable objectives.
  Why it matters: The approach is about how a platform is owned and used, not merely which tools it contains.
• Software delivery motivation: Explain why the introduction presents platform engineering as a response to software delivery challenges and why its potential value is not limited to large organizations.
  Why it matters: The motivation connects the platform approach to delivery friction rather than to organization size alone.

Key terms: engineering platform, infrastructure, governance, operational technologies, platform engineering, self-service capabilities, complete ownership, measurable business objectives, software quality, productivity

1.1 Platforms are more than just DevOps

This section shows why tool-heavy DevOps adoption can recreate delivery bottlenecks and introduces engineering platforms as a different way to serve development teams.

• Recurring DevOps Delivery Bottlenecks: Trace how moving infrastructure work and DevOps tools into development teams can lead to duplicated work, centralized queues, and slow delivery.
  Why it matters: It explains why adopting DevOps tools may not remove the delays a platform is meant to address.
• Need for Organizational Change: Explain why the section calls for looking beyond tools and existing ways of working when addressing delivery problems.
  Why it matters: It connects recurring bottlenecks to the need for a different organizational approach, not just more automation.
• Engineering Platform Alternative: Describe the development-oriented product this section calls an engineering platform and the role platform engineering plays in delivering it.
  Why it matters: It identifies the alternative the chapter proposes to repeated handoffs and delivery queues.

Key terms: DevOps tools, infrastructure as code, CI/CD, ticketed manner, organizational process flow, new model, platform engineering, engineering platform, self-service, cross-functional dependencies

1.1.1 Why should I care about platform engineering?

This section explains why internal engineering platforms are valuable and how self-service products can reduce developer friction while preserving required controls.

• Value of engineering platforms: Explain how a successful internal engineering platform can free developer time for strategically valuable work, increase confidence in security and governance compliance, and help a company expand development capacity.
  Why it matters: These are the outcomes that make changing how internal technology is delivered worthwhile.
• Internal technology as products: Explain why infrastructure and development technology teams should deliver products that developers can use easily and independently, rather than assuming that deciding to build a platform is enough.
  Why it matters: The product approach changes whether developers can actually benefit from internal capabilities.
• Self-service with required controls: Distinguish the centralized, ticket-based or exclusively controlled approaches from the platform approaches in the DNS and CI examples. Explain how the platform approaches reduce waiting while still enforcing the required outcomes.
  Why it matters: The examples show that reducing developer waiting does not require abandoning authorization or security checks.

Key terms: internal engineering platform, development capacity, security and governance compliance, product teams, internal developers, cognitive load, DNS, ingress definition, CI pipeline, pipeline step

1.2 When to use platform engineering principles

The section explains when to introduce platform engineering principles and how an organization’s stage affects that decision.

• Strategic value as the starting point: Explain why most organizations should begin intentionally incorporating platform engineering after identifying strategically valuable software development initiatives, rather than treating all development work as equally valuable.
  Why it matters: Identifying valuable work helps an organization decide where platform engineering investment is justified.
• Established organization adoption barriers: Describe why adopting platform engineering can be harder in an established organization without explicit product thinking and why some large companies create a separate division or company for new work.
  Why it matters: An established organization may need to account for organizational friction and a longer wait for benefits.
• Startup speed and technical debt: Explain how a startup’s need to acquire customers quickly affects its platform engineering choices, including what to do when it breaks principles for speed.
  Why it matters: Tracking genuine speed-for-debt tradeoffs makes it easier to revisit them if the startup succeeds.

Key terms: platform engineering, strategic value, software development initiatives, product thinking, internal organizational structures, digital division, startup, technical debt, platform engineering principles

1.2.1 When do these principles not apply?

This subsection explains when broad platform engineering investment may not be worthwhile, and why long-term savings or selective use of its principles may still justify action.

• Custom software strategic relevance: Explain why an organization whose success is not tied to custom software may have little reason to invest broadly in an engineering platform.
  Why it matters: A platform investment should reflect how much the organization depends on custom software.
• Long horizon efficiency benefits: Describe why platform engineering might still be worthwhile when time-to-market is less important.
  Why it matters: Faster delivery is not the only possible return on a platform investment.
• Selective use of principles: Explain why deciding against a whole platform does not require rejecting every platform engineering principle.
  Why it matters: An organization can benefit from selected principles without committing to the whole approach.

Key terms: strategic revenue, strategic effect, internal users, custom software, investment time horizon, technology resources, security, governance, time-to-market, platform engineering principles

1.3 Foundational concepts in platform engineering

The section introduces platform engineering as product delivery shaped by changing developer needs, feedback, and teams organized to deliver growing capabilities.

• Evolving user needs: Explain why a platform must keep responding to user needs rather than rely on an initially useful capability.
  Why it matters: An initially useful platform may lose users if it does not keep up with their needs.
• Developer feedback and roadmap: Describe how developer needs and feedback relate to the platform product roadmap.
  Why it matters: The roadmap stays connected to the people using the platform.
• Domain team organization: Explain why a growing platform needs organized teams and how the section describes their work.
  Why it matters: Team structure helps a growing platform keep delivering capabilities without sacrificing its intended product experience.

Key terms: product management, users’ needs, developer needs, feedback, product roadmap, domain-driven design, domain teams, shared engineering principles, product experience goals

1.3.1 Product delivery model for platforms

This section argues that internal engineering platforms should be delivered as products rather than as traditional infrastructure or developer tools.

• Platforms as internal products: Explain why an internal engineering platform should be managed like a product, and contrast that approach with traditional infrastructure and developer-tool delivery.
  Why it matters: A product approach keeps the platform focused on the developers it serves and the value it creates.

Key terms: product thinking, developer experience, internal engineering platform, adoption

1.3.2 Platform product domains

This section explains how domain boundaries can make an engineering platform easier to use and evolve, and how to apply an eight-domain model without assuming eight teams.

• User-centered domain boundaries: Explain how user experience guides the boundaries between platform domains and why those boundaries need deliberate design.
  Why it matters: Good boundaries let parts of the platform change without making it harder to use.
• Independent domain team coordination: Explain how well-bounded domain teams work independently while handling cross-domain dependencies, and why routine engineer-to-engineer coordination is a warning sign.
  Why it matters: Routine coordination friction can reveal that the platform’s team boundaries are not working as intended.
• Domains versus team count: Distinguish the eight-domain platform model from the number of teams needed to build it, and explain when to add independent teams.
  Why it matters: A team can use the domain model without creating an organization larger than demand justifies.
• Initial domain dependency order: Explain why some platform domains must be established before others when starting from scratch, while later allowing domains autonomy.
  Why it matters: The domain model allows independent evolution without ignoring prerequisites at launch.

Key terms: domain, domain boundary, user experience, loosely coupled, domain-bounded teams, backlog, product owners, domain-level architects, smell, eight domains

1.3.3 Platform engineering principles

This section explains seven connected principles that shape how platform teams design, deliver, govern, measure, and observe their capabilities.

• Software-defined self-service capabilities: Explain why platform capabilities should be deployable from versioned source control and designed around APIs that support self-service.
  Why it matters: These choices make platform capabilities repeatable to deliver and practical for developers to use without depending on another team for every action.
• Incrementally changeable architecture: Explain why platform architecture should accommodate rapid, small changes rather than aim for a fixed end-state.
  Why it matters: A platform can keep meeting users’ needs as circumstances and evidence change.
• Measured platform value: Explain how a platform team should use data to test whether features deliver their intended benefits across the organizational delivery process.
  Why it matters: Measurement helps distinguish real organization-wide improvement from a local improvement that merely moves the burden elsewhere.
• Shared security and resiliency: Distinguish the platform team’s security responsibilities from developers’ application-security responsibilities, and explain why the section treats resiliency as a platform security concern.
  Why it matters: A secure platform supports developers without pretending to take over their code security, and it must recover from failures that threaten service or data.
• Compliance at point of change: Describe how automated governance can give developers autonomy while providing security and governance stakeholders assurance.
  Why it matters: Verification at the point of change can provide assurance without making another team a bottleneck for developers.
• Observability beyond monitoring: Distinguish observability from monitoring and describe the range of information observability should connect.
  Why it matters: Broad visibility helps teams diagnose unanticipated problems and understand their effect on users.

Key terms: software-defined, self-service, API-first architecture, versioned source control, evolutionary architecture, incremental changes, metrics-driven success, technical health, value, shared responsibility model

1.4 Platform engineering enablers

The section introduces practices that help engineering platforms succeed and positions DevOps and SRE as supports for platform engineering, not practices it replaces.

• Platform engineering enablers: Explain what the section means by platform engineering enablers and why they matter to a platform.
  Why it matters: It frames these practices as contributors to platform success rather than unrelated activities.
• DevOps and SRE roles: Distinguish the section’s view of DevOps and SRE from the claim that platform engineering replaces them.
  Why it matters: It prevents the reader from treating platform engineering as a replacement for two practices the book presents as complementary.

Key terms: platform engineering enablers, catalysts, DevOps, site reliability engineering (SRE), platform engineering

1.4.1 Developer experience

Positions developer experience within an engineering platform and describes the developer tools and resources its product services provide.

• DevEx within platform strategy: Explain why developer experience is both an aim of the engineering platform and a subdomain within it, rather than a separate, competing effort.
  Why it matters: Clear boundaries help teams improve developer experience without competing over the same platform work.
• DevEx product service scope: Describe the kinds of developer tools and resources included in DevEx as a platform product service, and what they are intended to improve.
  Why it matters: Concrete examples make DevEx easier to recognize as a platform service rather than just a portal.

Key terms: developer experience (DevEx), engineering platform, internal subdomain, platform product services, language starter kits, contract testing automation, feature flag automation

1.4.2 DevOps

This section presents DevOps as a culture of shared responsibility across development and operations, including for engineering platforms.

• DevOps culture and ownership: Explain why DevOps is a culture rather than a team or job description, and describe how responsibility for software and platform capabilities extends from building them through production support.
  Why it matters: It makes production responsibility part of building software and the platform, rather than a separate handoff.

Key terms: DevOps, DevOps cultural models, engineering platform, platform engineers

1.4.3 SRE

This section explains SRE as temporary, embedded reliability work that improves product teams and the platform without creating a separate operational silo.

• SRE as continuous improvement: Explain how SRE enhances teams that already deliver and support software effectively, and how its contributions can spread beyond one team.
  Why it matters: Embedding SRE in mature teams lets reliability improvements become part of everyday delivery and benefit the wider platform.
• Shared product code ownership: Explain why a separate SRE codebase is a warning sign and where SREs contribute code instead.
  Why it matters: Where SREs contribute code shows whether they are improving product teams’ work or becoming a separate silo.

Key terms: SRE, reliability engineering, continuous quality improvement, engineering platform, SRE team, codebase, lifecycle code, product development team

1.4.4 Impact of generative AI in the platform engineering space

This section describes where generative AI can accelerate platform engineering work and why capable engineers must judge its output.

• AI assistance in platform work: Describe how current generative AI can accelerate repetitive or time-consuming platform engineering tasks, including observability analysis and architectural experimentation.
  Why it matters: These examples show where AI may save platform engineers time without replacing their work.
• Human judgment over AI output: Explain why engineers must evaluate generative AI's proposals rather than accept them at face value, and how the section frames its value.
  Why it matters: Human judgment is what makes AI assistance useful rather than a source of plausible-looking mistakes.

Key terms: generative AI, LLMs, observability data, architectural implementation and experimentation, hallucinations, comprehension

1.5 Let’s get started

Epetech’s growth exposes how fragmented infrastructure and release processes slow software delivery and increase risk.

• Growth and delivery demands: Explain why Epetech needs to deliver new customer experiences quickly while making its capabilities reusable.
  Why it matters: These business demands make delays and duplicated work especially costly for Epetech.
• Infrastructure coordination bottlenecks: Describe how Epetech’s fragmented infrastructure work affects developers and routine changes.
  Why it matters: The coordination burden explains why Epetech struggles even with routine infrastructure changes.
• Fragmented release feedback: Trace why Epetech’s release process reveals failures late and prolongs fixes.
  Why it matters: Late discovery and slow resolution compound the delays in Epetech’s software releases.

Key terms: composable, reusable, third-party developers, infrastructure lifecycle strategy, handoffs, lead-time planning, release candidates, bundled changes, development environment, testing environment

1.6 Summary