Platform Engineering

Publisher summary

Until recently, infrastructure was the backbone of organizations operating software they developed in-house. But now that cloud vendors run the computers, companies can finally bring the benefits of agile custom-centricity to their own developers. Adding product management to infrastructure organizations is now all the rage.

But how's that possible when infrastructure is still the operational layer of the company?

This practical book guides engineers, managers, product managers, and leaders through the shifts that modern platform-led organizations require. You'll learn what platform engineering is—and isn't—and what benefits and value it brings to developers and teams. You'll understand what it means to approach a platform as a product and learn some of the most common technical and managerial barriers to success.

With this book, you'll:

  • Cultivate a platform-as-product, developer-centric mindset
  • Learn what platform engineering teams are and are not
  • Start the process of adopting platform engineering within your organization
  • Discover what it takes to become a product manager for a platform team
  • Understand the challenges that emerge when you scale platforms
  • Automate processes and self-service infrastructure to speed development and improve developer experience
  • Build out, hire, manage, and advocate for a platform team

Table of contents

  • Foreword
  • Preface
    • A Note from Camille
    • Who This Book Is For
    • How to Read This Book
    • O’Reilly Online Learning
    • How to Contact Us
    • Acknowledgments
      • From Camille
      • From Ian
      • From Both of Us
  • I. The What and Why of Platform Engineering
  • 1. Why Platform Engineering Is Becoming Essential
    • Defining “Platform” and Other Important Terms
    • The Over-General Swamp
    • How We Got Stuck in the Over-General Swamp
      • Change #1: Explosion of Choice
      • Change #2: Higher Operational Needs
      • Result: Drowning in the Swamp
    • How Platform Engineering Clears the Swamp
      • Limiting Primitives While Minimizing Overhead
      • Reducing Per-Application Glue
      • Centralizing the Cost of Migrations
      • Allowing Application Developers to Operate What They Develop
    • Empowering Teams to Focus on Building Platforms
    • Wrapping Up
  • 2. The Pillars of Platform Engineering
    • Taking a Curated Product Approach
    • Developing Software-Based Abstractions
      • The Major Abstractions: Platform Service and Its APIs
      • Thick Clients
      • OSS Customizations
      • Integrating Metadata Registries
    • Serving a Broad Base of Application Developers
    • Operating as Foundations
      • Responsibility for the Full Platform
      • Supporting the Platform
      • Operational Discipline
    • Wrapping Up
  • II. Platform Engineering Practices
  • 3. How and When to Get Started
    • Fostering Platform Cooperation at Small Scale
    • Creating the Platform Teams That Replace Cooperation
      • Are the Benefits of Centralizing Ownership Worth the Costs?
      • Realize the Collective Dynamic Is Gone
      • Focus on Solving Problems, Not New Technology or Architecture
      • Beware of New Engineers Coming from Much Bigger Companies
      • Be Slow to Hire Product Managers (and Avoid Project Managers)
      • Bonus Problems for Integration/Shared Services Platforms
    • Transforming a Traditional Infrastructure Organization
      • Your Whole Engineering Culture Has to Change
      • Identify the Most Promising Areas to Start
      • Recognize That You Can’t Just Rub Product Managers on It and Call It a Day
      • Change the Way You Support Your Products
      • Update Your Interview Process
      • Update Your Systems of Recognition and Reward
      • Don’t Have Too Many Project Managers
      • Accept That Your Team Will Spend More Time Talking to Customers and Less Time Writing Code
      • Do the Necessary Restructuring
      • Keep It Fun!
    • Wrapping Up
  • 4. Building Great Platform Teams
    • The Risks of Single-Focus Platform Teams
      • Too Much Systems Focus
      • Too Much Development Focus
    • The Different Roles of Platform Engineers
      • Software Engineers
      • Systems Engineers
      • Reliability Engineers
      • Systems Specialists
    • Hiring and Recognizing Engineers in All Roles
      • Allow Role-Specific Titles
      • Avoid Creating a New Software Engineer Level Matrix
      • Have, at Most, One Level Matrix for the Systems Roles
      • If Needed, Create a New Software Engineer Interview Process
      • Vary the Interview Only Slightly for Systems Roles
      • Interview for Customer Empathy
    • What Makes a Great Platform Engineering Manager?
      • Experience Operating Platforms
      • Experience on Big, Long-Running Projects
      • Attention to Detail
    • Other Roles on a Platform Team
      • Product Managers
      • Product Owners
      • Project Managers/Technical Program Managers
      • Developer Advocates, Technical Writers, and Support Engineers
    • Creating a Platform Engineering Team Culture
      • A Platform Split Between a Development and an SRE Team
      • Strengths and Weaknesses of the Development Team
      • Merging the Teams and Adding Product Management
      • Instilling a Platform Engineering Culture
    • Wrapping Up
  • 5. Platform as a Product
    • Product Culture Focuses on the Customer
      • Characteristics of Internal Customers
      • Collaborating with Internal Customers
      • Empathizing with Customers
      • Escaping the Feature Shop Trap to Serve Customers More Broadly
    • Product Discovery and Market Analysis
      • Identifying Potential Platform Products
      • Evolving Existing Offerings: Smoothing the Edges or Rethinking the Problem
      • Market Research: Validating New Investments
      • Product Metrics
    • Successful Product Execution: Creating a Product Roadmap
      • Vision: Long Term
      • Strategy: Middle Term
      • Goals and Metrics: This Year
      • Milestones: Quarterly
      • The Customer-Facing Roadmap
      • Specification of Features
      • Practice Makes Perfect
    • Product Failure Modes
      • Underestimating the Migration Cost
      • Overestimating the Change Budget for Users
      • Overestimating the Value of New Features When Stability Is Poor
      • Having Too Many Product Managers for the Size of the Engineering Team
      • Having Product Managers Doing the Work That Engineering Managers Should Be Doing
    • Wrapping Up
  • 6. Operating Platforms
    • On-Call Practices
      • Why 24x7 On-Call Coverage Matters
      • Why Merged DevOps?
      • Getting to a Sustainable On-Call Load
    • Support Practices
      • Why Platform Engineers Should Do Support Work
      • Stage 1: Formalize Support Levels
      • Stage 2: Separate Noncritical Support from On-Call
      • Stage 3: Hire a Support Specialist
      • Stage 4: At Scale with an Engineering Support Organization
    • Operational Feedback Practices
      • SLOs and SLAs Are Necessary; Error Budgets Are Optional
      • Change Management
      • Synthetic Monitoring
      • Operational Reviews
    • Wrapping Up
  • 7. Planning and Delivery
    • Planning Long-Running Projects
      • Clarifying Goals and Requirements in a Proposal Document
      • Going from Proposal to Action Plan
      • Avoiding the Long Slog
    • Bottom-Up Roadmap Planning
      • “Keep the Lights On” Work
      • Mandates
      • System Improvements
      • Bringing It All Together
    • Communicating Status with Biweekly Wins and Challenges
      • The Basics
      • Why: What’s the Value?
      • What: Structuring Wins and Challenges Updates
      • Don’t Forget the Challenges!
      • Getting Your Team to Write Wins and Challenges
    • Wrapping Up
  • 8. Rearchitecting Platforms
    • Why Rearchitecting Is Preferred to Building a v2
      • Different Engineering Mindsets
      • Architectural Needs Drive Mindset Demands
      • Why It Is Hard to Build v2 Platforms, but Possible to Rearchitect
    • Addressing Security with Architecture
    • Guardrails for Rearchitectures
      • Compatibility
      • Testing
      • Lower Environments
      • Tranches, Slow Rollouts, and Staying a Version Behind
    • Planning for Rearchitectures
      • Step 1: Think Big on Final Rearchitecture Goals
      • Step 2: Factor in Migration Costs
      • Step 3: Determine Major 12-Month Wins
      • Step 4: Get Leadership Buy-in, and Be Prepared to Wait
    • Wrapping Up
  • 9. Migrations and Sunsetting of Platforms
    • Migration Antipatterns
    • Engineering Easier Migrations
      • Use Product Abstractions That Minimize Glue and Limit Variation
      • Architect for Transparent Migrations
      • Track Usage Metadata
      • Develop Automation to Avoid Clipboards
      • Document On-Ramps and Off-Ramps
    • Coordinating Smoother Migrations
      • Scope, Limit, and Prioritize Planned Changes
      • Communicate Early and Publicly
      • Push Through the Final 20%
      • Use Mandates Sparingly
    • Sunsetting Platforms
      • Deciding When to Sunset
      • Coordinating the Sunsetting
      • Don’t Be Afraid to Sunset When It Makes Sense
    • Wrapping Up
  • 10. Managing Stakeholder Relationships
    • Stakeholder Mapping: The Power-Interest Grid
    • Communicating with the Right Transparency
      • Beware of Oversharing Detail
      • Use Regular 1:1s Judiciously
      • Track Expectations and Commitments
      • Scale Up with Interlock Meetings and Customer Advisory Boards
      • Increase Communication During Rough Patches
    • Finding Acceptable Compromises
      • Be Clear About the Business Impact
      • Sometimes Say “Yes, with Compromises”
      • Saying “No” Without Ruining the Relationship
      • Compromising on Shadow Platforms
    • Money Troubles: Cost and Budget Management
      • Step 1: Figure Out Who Will Benefit Tomorrow
      • Step 2: Group the Work into Teams (Don’t Go Person-by-Person)
      • Step 3: Come with Suggestions of What to Cut and Strong Opinions About What to Keep
    • Wrapping Up
  • III. What Does Success Look Like?
  • 11. Your Platforms Are Aligned
    • Alignment to Purpose
      • Align Teams to Purpose with the Right Mix of People
      • Align Culture to Purpose with Common Practices
      • Align Culture to Purpose by Having Teams Collaborate
    • Alignment of Product Strategy
      • Foster Cross-Platform Thinking with Independent Product Management
      • Foster Cross-Platform Architecture with Independent Lead ICs
      • Seek Feedback from Comments in Platform-wide Customer Surveys
      • Judiciously Resolve Misalignment with Restructuring
    • Alignment of Plans
      • Align Only on Larger Projects, Not on Every Detail
      • Be Forthright in Confronting Misalignment
      • Final Alignment Comes from Principled Leadership
    • Tying It Together: Getting an Organization to Alignment
    • Wrapping Up
  • 12. Your Platforms Are Trusted
    • Trust in How You Operate
      • Accelerate Trust by Empowering Experienced Leaders
      • Optimize Growth in Trust by Ordering Use Cases
    • Trust in Your Big Investments
      • Seek Technical Stakeholder Buy-in for Trust of Rearchitectures
      • Seek Executive Sponsorship for Trust of New Products
      • Maintain Old Systems to Retain Trust
      • Gaining Trust Requires Flexibility on What Is “Right”
    • Trust to Prioritize Delivery
      • Create a Culture of Velocity
      • Prioritize Projects to Free Up Team Capacity
      • Challenge Assumptions About Product Scope
    • Tying It Together: The Case of the Overcoupled Platform
    • Wrapping Up
  • 13. Your Platforms Manage Complexity
    • Managing the Accidental Complexity of Human Coordination
    • Managing the Complexity of Shadow Platforms
    • Managing Complexity by Controlling Growth
    • Managing Complexity Through Product Discovery
    • Tying It Together: Balancing Internal and External Complexity
      • Burning Out on OSS Operations
      • Trying (and Failing) to Change the Game
      • Shadow Platforms Force a Reset
      • Executing on the Reset
    • Wrapping Up
  • 14. Your Platforms Are Loved
    • Love Just Works
    • Love Can Look Like a Hack
    • Love Can Be Obvious
    • Tying It Together: Love Makes Your Users Awesome
    • Wrapping Up: What Is Love? Baby Don’t Hurt Me
  • Concluding Remarks
  • Index
  • About the Authors
Hyperlink

Authorship

Camille Fournier
Ian Nowland

Tags

Design