book

Monolith to Microservices

by Sam Newman

November 2019

Intermediate to advanced

272 pages

7h 54m

English

O'Reilly Media, Inc.

Book available

Read now

Unlock full access

What You Will LearnConventions Used in This BookO’Reilly Online LearningHow to Contact UsAcknowledgments
What Are Microservices?Independent DeployabilityModeled Around a Business DomainOwn Their Own DataWhat Advantages Can Microservices Bring?What Problems Do They Create?User InterfacesTechnologySizeAnd OwnershipThe MonolithThe Single Process MonolithThe Distributed MonolithThird-Party Black-Box SystemsChallenges of MonolithsAdvantages of MonolithsOn Coupling and CohesionCohesionCouplingJust Enough Domain-Driven DesignAggregateBounded ContextMapping Aggregates and Bounded Contexts to MicroservicesFurther ReadingSummary
Understanding the GoalThree Key QuestionsWhy Might You Choose Microservices?Improve Team AutonomyReduce Time to MarketScale Cost-Effectively for LoadImprove RobustnessScale the Number of DevelopersEmbrace New TechnologyWhen Might Microservices Be a Bad Idea?Unclear DomainStartupsCustomer-Installed and Managed SoftwareNot Having a Good Reason!Trade-OffsTaking People on the JourneyChanging OrganizationsEstablishing a Sense of UrgencyCreating the Guiding CoalitionDeveloping a Vision and StrategyCommunicating the Change VisionEmpowering Employees for Broad-Based ActionGenerating Short-Term WinsConsolidating Gains and Producing More ChangeAnchoring New Approaches in the CultureImportance of Incremental MigrationIt’s Production That CountsCost of ChangeReversible and Irreversible DecisionsEasier Places to ExperimentSo Where Do We Start?Domain-Driven DesignHow Far Do You Have to Go?Event StormingUsing a Domain Model for PrioritizationA Combined ModelReorganizing TeamsShifting StructuresIt’s Not One Size Fits AllMaking a ChangeChanging SkillsHow Will You Know if the Transition Is Working?Having Regular CheckpointsQuantitative MeasuresQualitative MeasuresAvoiding the Sunk Cost FallacyBeing Open to New ApproachesSummary
To Change the Monolith, or Not?Cut, Copy, or Reimplement?Refactoring the MonolithMigration PatternsPattern: Strangler Fig ApplicationHow It WorksWhere to Use ItExample: HTTP Reverse ProxyData?Proxy OptionsChanging ProtocolsExample: FTPExample: Message InterceptionOther ProtocolsOther Examples of the Strangler Fig PatternChanging Behavior While Migrating FunctionalityPattern: UI CompositionExample: Page CompositionExample: Widget CompositionExample: Micro FrontendsWhere to Use ItPattern: Branch by AbstractionHow It WorksAs a Fallback MechanismWhere to Use ItPattern: Parallel RunExample: Comparing Credit Derivative PricingExample: Homegate ListingsVerification TechniquesUsing SpiesGitHub ScientistDark Launching and Canary ReleasingWhere to Use ItPattern: Decorating CollaboratorExample: Loyalty ProgramWhere to Use ItPattern: Change Data CaptureExample: Issuing Loyalty CardsImplementing Change Data CaptureWhere to Use ItSummary
Pattern: The Shared DatabaseCoping PatternsWhere to Use ItBut It Can’t Be Done!Pattern: Database ViewThe Database as a Public ContractViews to PresentLimitationsOwnershipWhere to Use ItPattern: Database Wrapping ServiceWhere to Use ItPattern: Database-as-a-Service InterfaceImplementing a Mapping EngineCompared to ViewsWhere to Use ItTransferring OwnershipPattern: Aggregate Exposing MonolithPattern: Change Data OwnershipData SynchronizationPattern: Synchronize Data in ApplicationStep 1: Bulk Synchronize DataStep 2: Synchronize on Write, Read from Old SchemaStep 3: Synchronize on Write, Read from New SchemaWhere to Use This PatternWhere to Use ItPattern: Tracer WriteData SynchronizationExample: Orders at SquareWhere to Use ItSplitting Apart the DatabasePhysical Versus Logical Database SeparationSplitting the Database First, or the Code?Split the Database FirstSplit the Code FirstSplit Database and Code TogetherSo, Which Should I Split First?Schema Separation ExamplesPattern: Split TableWhere to Use ItPattern: Move Foreign-Key Relationship to CodeMoving the JoinData ConsistencyWhere to Use ItExample: Shared Static DataTransactionsACID TransactionsStill ACID, but Lacking Atomicity?Two-Phase CommitsDistributed Transactions—Just Say NoSagasSaga Failure ModesImplementing SagasSagas Versus Distributed TransactionsSummary
More Services, More PainOwnership at ScaleHow Can This Problem Show Itself?When Might This Problem Occur?Potential SolutionsBreaking ChangesHow Can This Problem Show Itself?When Might This Problem Occur?Potential SolutionsReportingWhen Might This Problem Occur?Potential SolutionsMonitoring and TroubleshootingWhen Might These Problems Occur?How Can These Problems Occur?Potential SolutionsLocal Developer ExperienceHow Can This Problem Show Itself?When Might This Occur?Potential SolutionsRunning Too Many ThingsHow Might This Problem Show Itself?When Might This Problem Occur?Potential SolutionsEnd-to-End TestingHow Can This Problem Show Itself?When Might This Problem Occur?Potential SolutionsGlobal Versus Local OptimizationHow Can This Problem Show Itself?When Might This Problem Occur?Potential SolutionsRobustness and ResiliencyHow Can This Problem Show Itself?When Might This Problem Occur?Potential SolutionsOrphaned ServicesHow Can This Problem Show Itself?When Might This Problem Occur?Potential SolutionsSummary

Content preview from Monolith to Microservices

Chapter 1. Just Enough Microservices

Well, that escalated quickly, really got out of hand fast!

Ron Burgundy, Anchorman

Before we dive into how to work with microservices, it is important that we have a common, shared understanding about what microservice architectures are. I’d like to address some common misconceptions I see on a regular basis, as well as nuances that are often missed. You’ll need this firm foundation of knowledge to get the most out of what follows in the rest of the book. As such, this chapter will provide an explanation of microservice architectures, look briefly at how microservices developed (which means, naturally, taking a look at monoliths), and examine some of the advantages and challenges of working with microservices.

What Are Microservices?

Microservices are independently deployable services modeled around a business domain. They communicate with each other via networks, and as an architecture choice offer many options for solving the problems you may face. It follows that a microservice architecture is based on multiple collaborating microservices.

They are a type of service-oriented architecture (SOA), albeit one that is opinionated about how service boundaries should be drawn, and that independent deployability is key. Microservices also have the advantage of being technology agnostic.

From a technology viewpoint, microservices expose the business capabilities that they encapsulate via one or more network endpoints. Microservices communicate ...