book

Platform Engineering

by Camille Fournier, Ian Nowland

October 2024

Intermediate to advanced

324 pages

10h 45m

English

O'Reilly Media, Inc.

Read now

Unlock full access

A Note from CamilleWho This Book Is ForHow to Read This BookO’Reilly Online LearningHow to Contact UsAcknowledgmentsFrom CamilleFrom IanFrom Both of Us
Defining “Platform” and Other Important TermsThe Over-General SwampHow We Got Stuck in the Over-General SwampChange #1: Explosion of ChoiceChange #2: Higher Operational NeedsResult: Drowning in the SwampHow Platform Engineering Clears the SwampLimiting Primitives While Minimizing OverheadReducing Per-Application GlueCentralizing the Cost of MigrationsAllowing Application Developers to Operate What They DevelopEmpowering Teams to Focus on Building PlatformsWrapping Up
Taking a Curated Product ApproachDeveloping Software-Based AbstractionsThe Major Abstractions: Platform Service and Its APIsThick ClientsOSS CustomizationsIntegrating Metadata RegistriesServing a Broad Base of Application DevelopersOperating as FoundationsResponsibility for the Full PlatformSupporting the PlatformOperational DisciplineWrapping Up
Fostering Platform Cooperation at Small ScaleCreating the Platform Teams That Replace CooperationAre the Benefits of Centralizing Ownership Worth the Costs?Realize the Collective Dynamic Is GoneFocus on Solving Problems, Not New Technology or ArchitectureBeware of New Engineers Coming from Much Bigger CompaniesBe Slow to Hire Product Managers (and Avoid Project Managers)Bonus Problems for Integration/Shared Services PlatformsTransforming a Traditional Infrastructure OrganizationYour Whole Engineering Culture Has to ChangeIdentify the Most Promising Areas to StartRecognize That You Can’t Just Rub Product Managers on It and Call It a DayChange the Way You Support Your ProductsUpdate Your Interview ProcessUpdate Your Systems of Recognition and RewardDon’t Have Too Many Project ManagersAccept That Your Team Will Spend More Time Talking to Customers and Less Time Writing CodeDo the Necessary RestructuringKeep It Fun!Wrapping Up
The Risks of Single-Focus Platform TeamsToo Much Systems Focus Too Much Development FocusThe Different Roles of Platform EngineersSoftware EngineersSystems EngineersReliability EngineersSystems SpecialistsHiring and Recognizing Engineers in All RolesAllow Role-Specific TitlesAvoid Creating a New Software Engineer Level MatrixHave, at Most, One Level Matrix for the Systems RolesIf Needed, Create a New Software Engineer Interview ProcessVary the Interview Only Slightly for Systems RolesInterview for Customer EmpathyWhat Makes a Great Platform Engineering Manager?Experience Operating PlatformsExperience on Big, Long-Running ProjectsAttention to DetailOther Roles on a Platform TeamProduct ManagersProduct OwnersProject Managers/Technical Program ManagersDeveloper Advocates, Technical Writers, and Support EngineersCreating a Platform Engineering Team CultureA Platform Split Between a Development and an SRE TeamStrengths and Weaknesses of the Development TeamMerging the Teams and Adding Product ManagementInstilling a Platform Engineering CultureWrapping Up
Product Culture Focuses on the CustomerCharacteristics of Internal CustomersCollaborating with Internal CustomersEmpathizing with CustomersEscaping the Feature Shop Trap to Serve Customers More BroadlyProduct Discovery and Market AnalysisIdentifying Potential Platform ProductsEvolving Existing Offerings: Smoothing the Edges or Rethinking the ProblemMarket Research: Validating New InvestmentsProduct MetricsSuccessful Product Execution: Creating a Product RoadmapVision: Long TermStrategy: Middle TermGoals and Metrics: This YearMilestones: QuarterlyThe Customer-Facing RoadmapSpecification of FeaturesPractice Makes PerfectProduct Failure ModesUnderestimating the Migration CostOverestimating the Change Budget for UsersOverestimating the Value of New Features When Stability Is PoorHaving Too Many Product Managers for the Size of the Engineering TeamHaving Product Managers Doing the Work That Engineering Managers Should Be DoingWrapping Up
On-Call PracticesWhy 24x7 On-Call Coverage MattersWhy Merged DevOps?Getting to a Sustainable On-Call LoadSupport PracticesWhy Platform Engineers Should Do Support WorkStage 1: Formalize Support LevelsStage 2: Separate Noncritical Support from On-CallStage 3: Hire a Support SpecialistStage 4: At Scale with an Engineering Support OrganizationOperational Feedback PracticesSLOs and SLAs Are Necessary; Error Budgets Are OptionalChange ManagementSynthetic MonitoringOperational ReviewsWrapping Up

Planning Long-Running ProjectsClarifying Goals and Requirements in a Proposal DocumentGoing from Proposal to Action PlanAvoiding the Long SlogBottom-Up Roadmap Planning“Keep the Lights On” WorkMandatesSystem ImprovementsBringing It All TogetherCommunicating Status with Biweekly Wins and ChallengesThe BasicsWhy: What’s the Value?What: Structuring Wins and Challenges UpdatesDon’t Forget the Challenges!Getting Your Team to Write Wins and ChallengesWrapping Up
Why Rearchitecting Is Preferred to Building a v2 Different Engineering MindsetsArchitectural Needs Drive Mindset DemandsWhy It Is Hard to Build v2 Platforms, but Possible to RearchitectAddressing Security with ArchitectureGuardrails for RearchitecturesCompatibilityTestingLower EnvironmentsTranches, Slow Rollouts, and Staying a Version BehindPlanning for Rearchitectures Step 1: Think Big on Final Rearchitecture GoalsStep 2: Factor in Migration CostsStep 3: Determine Major 12-Month WinsStep 4: Get Leadership Buy-in, and Be Prepared to WaitWrapping Up
Migration AntipatternsEngineering Easier MigrationsUse Product Abstractions That Minimize Glue and Limit VariationArchitect for Transparent MigrationsTrack Usage MetadataDevelop Automation to Avoid Clipboards Document On-Ramps and Off-RampsCoordinating Smoother MigrationsScope, Limit, and Prioritize Planned ChangesCommunicate Early and PubliclyPush Through the Final 20%Use Mandates SparinglySunsetting Platforms Deciding When to SunsetCoordinating the SunsettingDon’t Be Afraid to Sunset When It Makes SenseWrapping Up
Stakeholder Mapping: The Power-Interest GridCommunicating with the Right TransparencyBeware of Oversharing DetailUse Regular 1:1s JudiciouslyTrack Expectations and CommitmentsScale Up with Interlock Meetings and Customer Advisory BoardsIncrease Communication During Rough PatchesFinding Acceptable CompromisesBe Clear About the Business ImpactSometimes Say “Yes, with Compromises”Saying “No” Without Ruining the RelationshipCompromising on Shadow PlatformsMoney Troubles: Cost and Budget ManagementStep 1: Figure Out Who Will Benefit TomorrowStep 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 KeepWrapping Up
Alignment to PurposeAlign Teams to Purpose with the Right Mix of PeopleAlign Culture to Purpose with Common PracticesAlign Culture to Purpose by Having Teams CollaborateAlignment of Product StrategyFoster Cross-Platform Thinking with Independent Product ManagementFoster Cross-Platform Architecture with Independent Lead ICsSeek Feedback from Comments in Platform-wide Customer SurveysJudiciously Resolve Misalignment with RestructuringAlignment of PlansAlign Only on Larger Projects, Not on Every DetailBe Forthright in Confronting MisalignmentFinal Alignment Comes from Principled LeadershipTying It Together: Getting an Organization to AlignmentWrapping Up
Trust in How You OperateAccelerate Trust by Empowering Experienced LeadersOptimize Growth in Trust by Ordering Use CasesTrust in Your Big InvestmentsSeek Technical Stakeholder Buy-in for Trust of Rearchitectures Seek Executive Sponsorship for Trust of New ProductsMaintain Old Systems to Retain TrustGaining Trust Requires Flexibility on What Is “Right”Trust to Prioritize DeliveryCreate a Culture of VelocityPrioritize Projects to Free Up Team CapacityChallenge Assumptions About Product ScopeTying It Together: The Case of the Overcoupled PlatformWrapping Up
Managing the Accidental Complexity of Human CoordinationManaging the Complexity of Shadow PlatformsManaging Complexity by Controlling GrowthManaging Complexity Through Product DiscoveryTying It Together: Balancing Internal and External ComplexityBurning Out on OSS OperationsTrying (and Failing) to Change the GameShadow Platforms Force a ResetExecuting on the ResetWrapping Up
Love Just WorksLove Can Look Like a HackLove Can Be ObviousTying It Together: Love Makes Your Users AwesomeWrapping Up: What Is Love? Baby Don’t Hurt Me

Content preview from Platform Engineering

Chapter 3. How and When to Get Started

Once upon a time, there were three little pigs. One pig built a house of straw, while the second pig built his house with sticks. They built their houses very quickly and then sang and danced all day because they were lazy. The third little pig worked hard all day and built his house with bricks.

“The Three Little Pigs”

This chapter is targeted at those leaders whose teams are not doing platform engineering yet. (Those who are doing it already can skip straight to Chapter 4). We focus on three specific starting points:

In the first section, we talk about what it means to do platform engineering at a small startup, where it’s usually best to start by building cooperation around your shared code.
In the second section, we cover how to handle the transition to a formal platform engineering organization when those initial cooperative mechanisms start to fail.
In the final section, we cover a different problem that’s typically encountered in older and larger companies: transitioning a traditional infrastructure engineering team into a platform engineering culture.

Sometimes it’s OK to build your platform quickly from straw and sticks and use the extra time to build more important things for the business.¹ But it’s good to know when you need to start laying bricks and how to start renovating your old stone castle into something more modern.