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

Overview

How do you detangle a monolithic system and migrate it to a microservice architecture? How do you do it while maintaining business-as-usual? As a companion to Sam Newman’s extremely popular Building Microservices, this new book details a proven method for transitioning an existing monolithic system to a microservice architecture.

With many illustrative examples, insightful migration patterns, and a bevy of practical advice to transition your monolith enterprise into a microservice operation, this practical guide covers multiple scenarios and strategies for a successful migration, from initial planning all the way through application and database decomposition. You’ll learn several tried and tested patterns and techniques that you can use as you migrate your existing architecture.

Ideal for organizations looking to transition to microservices, rather than rebuild
Helps companies determine whether to migrate, when to migrate, and where to begin
Addresses communication, integration, and the migration of legacy systems
Discusses multiple migration patterns and where they apply
Provides database migration examples, along with synchronization strategies
Explores application decomposition, including several architectural refactoring patterns
Delves into details of database decomposition, including the impact of breaking referential and transactional integrity, new failure modes, and more