book

Enabling Microservice Success

by Sarah Wells

March 2024

Intermediate to advanced

450 pages

12h 48m

English

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

Includes

Includes Quizzes

Why I Wrote This BookWho Should Read This BookNavigating This BookPart I: ContextPart II: Organizational Structure and CulturePart III: Building and OperatingAppendixesCase StudiesConventions Used in This BookO’Reilly Online LearningHow to Contact UsAcknowledgments
Defining the Microservices Architectural StyleA Suite of ServicesEach Running in Its Own ProcessCommunicating with Lightweight MechanismsBuilt Around Business CapabilitiesIndependently Deployable“Small”With a Bare Minimum of Centralized ManagementHeterogeneousForerunners and AlternativesThe MonolithModular MonolithsService-Oriented ArchitectureThe Microservices EcosystemInfrastructure as CodeContinuous DeliveryThe Public CloudNew Deployment OptionsDevOpsObservabilityAdvantages of MicroservicesIndependently ScalableRobustEasy to Release Small Changes FrequentlySupport Flexible Technology ChoicesChallenges of MicroservicesLatencyEstate ComplexityOperational ComplexityData ConsistencySecurityFinding the Right Level of GranularityHandling ChangeRequire Organizational ChangeChange the Developer ExperienceIn Summary
Regularly Delivering Business ValueHigh Deployment FrequencyShort Lead Time for ChangesRunning ExperimentsSeparating Deploying Code from Releasing FunctionalityHandling Work That Goes Across Team BoundariesAdapting to Changing PrioritiesMaintaining Appropriate Service LevelsWhen a Release Goes WrongKnowing When Something Important Is BrokenRestore Some Level of Service QuicklyAvoid Failure CascadesSpending Most of Your Time on Meaningful WorkNot Having to Start AgainKeeping Risk at an Acceptable LevelHow Microservices Measure UpIn Summary
Reasons to Choose MicroservicesScaling the OrganizationDeveloper ExperienceSeparating Out Areas with Compliance and Security RequirementsScaling for LoadIncreasing RobustnessIncreasing FlexibilityConditions for SuccessDomain UnderstandingProducts Not ProjectsLeadership SupportTeams That Want AutonomyProcesses That Enable AutonomyTechnical MaturityManaging ChangeSticking with a Monolithic ArchitectureEnable Zero-Downtime DeploymentsBuild a Modular MonolithEverything Is Distributed NowThe Rise of Cloud NativeSaaS Makes SenseRecommendationsStarting from ScratchReplacing an Existing MonolithMeasuring SuccessIn Summary
Conway’s LawThe Inverse Conway ManeuverPossible BoundariesBusiness DomainsLocationsTechnologiesComplianceTolerance for FailureFrequency of ChangesRecommendationsIdentifying When Boundaries Are WrongIn Summary
Organizational CultureOpenLearningEmpoweringOptimized for ChangeThe Westrum ModelEffective TeamsMotivated through Autonomy, Mastery, and PurposeAligned to Business DomainAppropriately SizedCross-Functional and T-shapedStrong OwnershipLong LivedSustainable Cognitive LoadHigh Trust and High Psychological SafetyPart of a GroupOptimizing for FlowStream-AlignedEnablingComplicated SubsystemPlatformIn Summary
What Is Autonomy?Why Does Autonomy Matter?Limits to AutonomyThe Right Amount of CommunicationInteraction StylesCollaborationX-as-a-ServiceFacilitatingWays of Working That Support AutonomyAligning on OutcomesLight Touch GovernanceTrust but VerifyAgreeing and Aligning on TechnologyThe Role of the Individual ContributorMinimum Viable CompetenciesMaking Space for LearningResponsibilities of Autonomous TeamsActive OwnershipCommunication and CooperationCompliance with StandardsMaintaining a Team PageIn Summary

What’s in a Name?Building a PlatformPlatform ServicesOrganization-Level ConcernsBuilding the Thinnest Viable PlatformBuild for the Needs of the MajorityPlatform as a ProductBeyond the PlatformVendor EngineeringAPIs, Templates, Libraries, and ExamplesA Service CatalogInsightsPaving the RoadWhat Capabilities to IncludeMake It OptionalKeep It SmallHow to Go Off RoadBringing the Treasure BackInternal Developer PortalsBuilding a Platform People Actually UseMaking Sure What You Build Meets a NeedMarket ItLook for Signs You Are Getting It WrongPrinciples for Building a Paved RoadOptionalProvides ValueSelf-ServiceOwned and SupportedEasy to UseGuides People to Do the Right ThingComposable and ExtendableMeasuring ImpactWhen to Invest in Engineering EnablementIn Summary
Why Microservices Implies DevOpsRelease on DemandWork on Operational FeaturesBuilding Things DifferentlyGood RunbooksRunning on Someone Else’s ServersGetting Comfortable in ProductionSupporting Your System in ProductionAssign Dedicated In-Hours Ops SupportImprove Alerts and DocumentationIdentify the Haunted ForestsPracticeOut-of-Hours SupportAllow People to Opt OutFormal Rotas Versus Best EndeavorsMake Sure Calls Are RareOnly for Critical SystemsProvide Support and GuidanceIncident ManagementBlameless CultureRaising an IncidentRoles to AssignDuring the IncidentAfter the IncidentLearning from IncidentsIn Summary
Responding to the Log4Shell VulnerabilityA Counter Example: Equifax and a Struts VulnerabilityOwnership During Active DevelopmentStrong OwnershipWeak OwnershipCollective OwnershipOnce a Service Is Feature CompleteNo OwnershipNominal OwnershipActive OwnershipWhat Active Ownership MeansCode StewardshipUpgrades and PatchingMigrationsProduction SupportDocumentationKnowing Your EstateYour Own SoftwareDependenciesThird-Party SoftwareWhat You Need from a Service CatalogGraph-Based ModelAPI-DrivenExtensibleFlexible SchemaProvides Different Views Across the EstateTransferring OwnershipWhat Does a Good Transfer Look Like?Meeting Quality ExpectationsOperational HandoverReplacingWhat to Do If You’re StrugglingMake the Business CaseStart with Critical SystemsMake Your Best Guess at OwnersDeliver Value from the DataAim for Continuous ImprovementLook for Teams That Are OverwhelmedServices Shouldn’t Live ForeverIn Summary
Why Do We Test?Building the Thing RightBuilding the Right ThingPicking Up RegressionsMeeting Quality-of-Service RequirementsShifting Testing LeftWhat Makes a Good Test?Fast and Early FeedbackEasy to ChangeFinds Real ProblemsTypes of TestingThe Testing PyramidUnit TestsService TestsEnd-to-End TestsContract TestsConsistency TestsExploratory TestsCross-Functional TestingTesting in ProductionIs It Safe?Staging Is Not Production-LikeYour Customers Can Surprise YouYou Can’t Test for Every VariationYou Don’t Have to Roll a Change Out to EveryoneMonitoring as TestingTesting Your InfrastructureChaos EngineeringTesting Failovers and RestoresQuality Is About More Than TestingWhat to Do If You’re StrugglingNot Enough Automated TestingTests That Aren’t Providing ValueIn Summary
Why Governance MattersKnow Your EstateWhat Sort of Information Is Relevant?Guardrails and PoliciesAutomating GuardrailsWhat to IncludeThe FT’s GuardrailsAligning on GuardrailsTech Governance GroupBenefits of the TGGChoosing TechnologiesThe Technology LifecycleSave Innovation for Key Business OutcomesUse Boring TechnologyLimit the AlternativesBe Clear on Where Duplication Is AcceptableExpect Things to ChangeInsight Leads to ActionGovernance in Other OrganizationsGovernance at MonzoGovernance at SkyscannerWhat to Do If You’re StrugglingIn Summary
What Is Resilience?Resilience for Distributed SystemsResilience for MicroservicesUnderstanding Your Service Level RequirementsService Level ObjectivesError BudgetsBuilding Resilient ServicesRedundancyFast Startup and Graceful ShutdownSet Appropriate TimeoutsBack Off and RetryMake Your Requests IdempotentProtect YourselfTesting Service ResilienceMake Building Resilient Services EasyBuilding Resilient SystemsCachingHandling Cascading FailuresFallback BehaviorAvoiding Unnecessary WorkGo AsynchronousFailoverBackup and RestoreDisaster RecoveryBuilding a Resilient PlatformResilience to External IssuesInternal ToolingValidating Your Resilience ChoicesChaos EngineeringTesting Backup and RestorePractice Makes PerfectLoad TestingLearn from IncidentsOne Thing at a TimeWhat to Do If You’re StrugglingIn Summary
Operational Challenges of MicroservicesDifferent Technologies Mean Different Support Knowledge Is NeededEphemeral InfrastructureRapid ChangeAlert OverloadComplex Systems Run in Degraded ModeBuilding Observability InLoggingMonitoring and MetricsLog AggregationOpenTelemetryFocus on EventsDistributed TracingArchiving Observability DataBuilding Your Own ToolsSpotting IssuesGetting Alerting RightHealthchecksMonitoring Business OutcomesUnderstanding What Normal Looks LikeMitigationTroubleshootingMaintaining Useful DocumentationKnowing What’s ChangedProblems with External SystemsTooling CharacteristicsLearning from IncidentsWhat to Do If You’re StrugglingIn Summary
Why Is This a Challenge?Minimizing the Impact of ChangeThink About the Long TermA Reason to Be on the Paved RoadChoose Managed Services and SaaS OptionsProvide APIsImmutable and Ephemeral InfrastructureDecommission and DeprecateTypes of ChangeEmergency ChangesMinor Planned ChangesMajor Planned ChangesResponding to ChangeUnderstand the LandscapeDefine Guiding PoliciesMaking a DecisionWho Gets to Decide?Scheduling WorkManaging ChangeClarityCommunicationEmpathyExecutionWhat to Do If You’re StrugglingIn Summary
Why Microservices?The Importance of FlowSupport for AutonomyThe Rise of Platform EngineeringWrapping Up
Do You Need Microservices?Scaling ChallengesTechnical ReasonsSpotting Potential PitfallsOrganizational Structure and CultureSoftware Delivery Approach
Part I: ContextPart II: Organizational Structure and CulturePart III: Building and Operating

Overview

Microservices can be a very effective approach for delivering value to your organization and to your customers. If you get them right, microservices help you to move fast by making changes to small parts of your system hundreds of times a day. But if you get them wrong, microservices will just make everything more complicated.

In this book, technical engineering leader Sarah Wells provides practical, in-depth advice for moving to microservices. Having built her first microservice architecture in 2013 for the Financial Times, Sarah discusses the approaches you need to take from the start and explains the potential problems most likely to trip you up. You'll also learn how to maintain the architecture as your systems mature while minimizing the time you spend on support and maintenance.

With this book, you will:

Learn the impact of microservices on software development patterns and practices
Identify the organizational changes you need to make to successfully build and operate this architecture
Determine the steps you must take before you move to microservices
Understand the traps to avoid when you create a microservices architecture—and learn how to recover if you fall into one