Platform Engineering Camille Fournier, Ian Nowland

Spis treści książki

• Foreword
• Preface
  • A Note from Camille
  • Who This Book Is For
  • How to Read This Book
  • OReilly 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 Cant 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
    • Dont 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
      • What they do well
      • What they do badly
      • Why they are stuck
    • Too Much Development Focus
      • What they do well
      • What they do badly
      • Why they are stuck
  • 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
      • Assimilate and expand
      • Partner to prototype
      • Look for products with realistic paths to adoption
      • You arent Google, so dont build when you dont have to
    • Evolving Existing Offerings: Smoothing the Edges or Rethinking the Problem
    • Market Research: Validating New Investments
      • Product-market fit is context-dependent
      • Who are you targeting?
      • Whats the appetite for immediate adoption?
    • 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
      • Prioritize stability
      • Eliminate false alarms
      • Use another platform team for secondary rotation
      • Paying for on-call coverage wont make an unsustainable load better
  • 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
      • Operational reviews are essential for platform teams
      • Keep team reviews simple and rigorous
      • Org-level reviews are essential, but put practice over process
      • Leadership engagement drives the right outcomes
  • 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
      • Overreach
      • Starting too big
      • Unclear problem space
      • Project team turnover
  • Bottom-Up Roadmap Planning
    • Keep the Lights On Work
    • Mandates
    • System Improvements
      • Reliability and operability improvements
      • Efficiency and performance improvements
      • Security and compliance improvements
    • Bringing It All Together
      • Cadence
      • Merging lists
      • Merging roadmaps of platform teams
  • Communicating Status with Biweekly Wins and Challenges
    • The Basics
    • Why: Whats the Value?
    • What: Structuring Wins and Challenges Updates
    • Dont Forget the Challenges!
    • Getting Your Team to Write Wins and Challenges
      • Who should write the updates?
      • Who should receive the updates?
  • 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
      • Look to all categories of system capability
      • Look at subsuming adjacent systems
      • Look to big bets around OSS and vendor systems
    • 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
    • Dont 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 (Dont 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 Dont Hurt Me
• Concluding Remarks
• Index

pokaż cały spis treści

ukryj recenzje