Monolith to Microservices

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 architecure.

With many illustrative examples, insightful migration patterns, and a bevy of practical advice to transition your monolith to a microservice platform, 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

1. Just Enough Microservices
• What Are Microservices?
• Independent Durability
• Modeled Around a Business Domain
• Own Their Own Data
• What Advantages Can Microservices Bring?
• What Problems Do They Create?
• User Interfaces
• Technology
• Size
• And Ownership
• The Monolith
• The Single Process Monolith
• The Distributed Monolith
• Third-Party Black-Box Systems
• Challenges of Monoliths
• Advantages of Monoliths
• On Coupling and Cohesion
• Cohesion
• Coupling
• Just Enough Domain-Driven Design
• Aggregate
• Bounded Context
• Mapping Aggregates and Bounded Contexts to Microservices
• Further Reading
• Summary
2. Planning a Migration
• Understanding the Goal
• Three Key Questions
• Why Might You Choose Microservices?
• Improve Team Autonomy
• Reduce Time to Market
• Scale Cost-Effectiveness for Load
• Improve Robustness
• Scale the Number of Developers
• Embrace New Technology
• When Might Microservices Be a Bad Idea?
• Unclear Domain
• Startups
• Customer-Installed and Managed Software
• Not Having a Good Reason!
• Trade-Offs
• Taking People on the Journey
• Changing Organizations
• Establishing a Sense of Urgency
• Creating the Guiding Coalition
• Developing a Vision and Strategy
• Communicating the Change Vision
• Empowering Employees for Broad-Based Action
• Generating Short-Term Wins
• Consolidating Gains and Producing More Change
• Anchoring New Approaches in the Culture
• Importance of Incremental Migration
• It's Production That Counts
• Cost of Change
• Reversible and Irreversible Decisions
• Easier Place to Experiment
• So Where Do We Start?
• Domain-Driven Design
• How Far Do You Have to Go?
• Event Storming
• Using a Domain Model for Prioritization
• A Combined Model
• Reorganizing Teams
• Shifting Structures
• It's Not One Size Fits All
• Making a Change
• Changing Skills
• How Will You Know if the Transition Is Working?
• Having Regular Checkpoints
• Quantitative Measures
• Qualitative Measures
• Avoiding the Sunk Cost Fallacy
• Being Open to New Approaches
• Summary
3. Splitting the Monolith
• To Change the Monolith, or Not?
• Cut, Copy, or Reimplement?
• Refactoring the Monolith
• Migration Patterns
• Pattern: Strangler Fig Application
• How It Works
• Where to Use It
• Example: HTTP Reverse Proxy
• Data?
• Proxy Options
• Changing Protocols
• Example: FTP
• Example: Message Interception
• Other Protocols
• Other Examples of the Strangler Fig Pattern
• Changing Behavior While Migrating Functionality
• Pattern: UI Composition
• Example: Page Composition
• Example: Widget Composition
• Example: Micro Frontends
• Where to Use It
• Pattern: Branch by Abstraction
• How It Works
• As a Fallback Mechanism
• Where to Use It
• Pattern: Parallel Run
• Example: Comparing Credit Derivative Pricing
• Example: Homegate Listings
• Verification Techniques
• Using Spies
• GitHub Scientist
• Dark Launching and Canary Releasing
• Where to Use It
• Pattern: Decorating Collaborator
• Example: Loyalty Program
• Where to User It
• Pattern: Change Data Capture
• Example: Issuing Loyalty Cards
• Implementing Change Data Capture
• Where to Use It
• Summary
4. Decomposing the Database
• Pattern: The Shared Database
• Coping Patterns
• Where to Use It
• But It Can't Be Done!
• Pattern: Database View
• The Database as a Public Contract
• Views to Present
• Limitations
• Ownership
• Where to Use It
• Pattern: Database Wrapping Service
• Where to Use It
• Pattern: Database-as-a-Service Interface
• Implementing a Mapping Engine
• Compared to Views
• Where to Use It
• Transferring Ownership
• Pattern: Aggregate Exposing Monolith
• Pattern: Change Data Ownership
• Data Synchronization
• Pattern: Synchronize Data in Application
• Step 1: Bulk Synchronize Data
• Step 2: Synchronize on Write, Read from Old Schema
• Step 3: Synchronize on Write, Read from New Schema
• Where to Use This Pattern
• Where to Use it
• Pattern: Tracer Write
• Data Synchronization
• Example: Orders at Square
• Where to Use It
• Splitting Apart the Database
• Physical Versus Logical Database Separation
• Splitting the Database First, or the Code?
• Split the Database First
• Split the Code First
• Split Database and Code Together
• So, Which Should I Split First?
• Schema Separation Examples
• Pattern: Split Table
• Where to Use It
• Pattern: Move Foreign-Key Relationship to Code
• Moving the Join
• Data Consistently
• Where to Use It
• Example: Shared Static Data
• Transactions
• ACID Transactions
• Still ACID, but Lacking Atomicity?
• Two-Phase Commits
• Distributed Transactions — Just Say No
• Sagas
• Saga Failure Modes
• Implementing Sagas
• Sagas Versus Distributed Transactions
• Summary
5. Growing Pains
• More Services, More Pain
• Ownership at Scale
• How Can This Problem Show Itself?
• When Might This Problem Occur?
• Potential Solutions
• Breaking Changes
• How Can This Problem  Show Itself?
• When Might This Problem Occur?
• Potential Solutions
• Reporting
• When Might This Problem Show Itself?
• Potential Solutions
• Monitoring and Troubleshooting
• When Might These Problems Occur?
• How Can These Problems Occur?
• Potential Solutions
• Local Developer Experience
• How Can This Problem Show Itself?
• When Might This Occur?
• Potential Solutions
• Running Too Many Things
• How Can This Problem Show Itself?
• When Might This Occur?
• Potential Solutions
• End-to-End Testing
• How Can This Problem Show Itself?
• When Might This Occur?
• Potential Solutions
• Global Versus Local Optimization
• How Can This Problem Show Itself?
• When Might This Occur?
• Potential Solutions
• Robustness and Resiliency
• How Can This Problem Show Itself?
• When Might This Occur?
• Potential Solutions
• Orphaned Services
• How Can This Problem Show Itself?
• When Might This Occur?
• Potential Solutions
• Summary
6. Closing Words

A book that describes a lot of patterns and traps you may fall into when moving your old legacy app to microservices. It is not in any way bad, but the audience seems to be inexperienced programmers, that have a limited experience and analytical mind to draw conclusions from.

If you have 5+ years of experience of real applications, you won't need this book, but if you start in the business, it is a valuable introduction on how to think (not only for microservices, but partitioning of applications, databases, etc.)