Monolith to Microservices. Evolutionary Patterns Chorzów

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 rebuildHelps companies determine whether to migrate, when to migrate, and where to beginAddresses communication, integration, and the migration of legacy systemsDiscusses multiple migration patterns and where they applyProvides database migration examples, along with synchronization strategiesExplores application decomposition, including several architectural refactoring patternsDelves into details of database decomposition, including the impact of breaking referential and transactional integrity, new failure modes, and more Spis treści: Preface What You Will Learn Conventions Used in This Book OReilly Online Learning How to Contact Us Acknowledgments 1. Just Enough Microservices What Are Microservices? Independent Deployability 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 And the modular monolith The Distributed Monolith Third-Party Black-Box Systems Challenges of Monoliths Advantages of Monoliths On Coupling and Cohesion Cohesion Coupling Implementation coupling Temporal coupling Deployment coupling Domain 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 How else could you do this? Reduce Time to Market How else could you do this? Scale Cost-Effectively for Load How else could you do this? Improve Robustness How else could you do this? Scale the Number of Developers How else could you do this? Embrace New Technology How else could you do this? 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 Its Production That Counts Cost of Change Reversible and Irreversible Decisions Easier Places 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 Its 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 A modular monolith? Incremental rewrites Migration Patterns Pattern: Strangler Fig Application How It Works Where to Use It Example: HTTP Reverse Proxy Step 1: Insert proxy Step 2: Migrate functionality Step 3: Redirect calls Data? Proxy Options Incremental rollout Changing Protocols And service meshes Example: FTP Example: Message Interception Content-based routing Selective consumption Other Protocols Other Examples of the Strangler Fig Pattern Changing Behavior While Migrating Functionality Pattern: UI Composition Example: Page Composition Example: Widget Composition And mobile applications Example: Micro Frontends Where to Use It Pattern: Branch by Abstraction How It Works Step 1: Create abstraction Step 2: Use abstraction Step 3: Create new implementation Step 4: Switch implementation Step 5: Clean up 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 Use It Pattern: Change Data Capture Example: Issuing Loyalty Cards Implementing Change Data Capture Database triggers Transaction log pollers Batch delta copier Where to Use It Summary 4. Decomposing the Database Pattern: The Shared Database Coping Patterns Where to Use It But It Cant 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 As a pathway to more services Where to use it Where to use it Pattern: Change Data Ownership Where to use it 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 Creating the new service Synchronizing the data Migrating consumers Where to Use It Splitting Apart the Database Physical Versus Logical Database Separation Splitting the Database First, or the Code? Split the Database First Pattern: Repository per bounded context Where to use it Pattern: Database per bounded context Where to use it Split the Code First Pattern: Monolith as data access layer Where to use it Pattern: Multischema storage Where to use it 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 Consistency Check before deletion Handle deletion gracefully Dont allow deletion So how should we handle deletion? Where to Use It Example: Shared Static Data Pattern: duplicate static reference data Where to use it Pattern: Dedicated reference data schema Where to use it Pattern: Static reference data library Where to use it Pattern: Static reference data service Where to use it What would I do? Transactions ACID Transactions Still ACID, but Lacking Atomicity? Two-Phase Commits Distributed TransactionsJust Say No Sagas Saga Failure Modes Saga rollbacks Reordering steps to reduce rollbacks Mixing fail-backward and fail-forward situations Implementing Sagas Orchestrated sagas Choreographed sagas Mixing styles Should I use choreography or orchestration? 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 Eliminate accidental breaking changes Think twice before making a breaking change Give consumers time to migrate Reporting When Might This Problem Occur? Potential Solutions Monitoring and Troubleshooting When Might These Problems Occur? How Can These Problems Occur? Potential Solutions Log aggregation Tracing Test in production Toward observability Local Developer Experience How Can This Problem Show Itself? When Might This Occur? Potential Solutions Running Too Many Things How Might This Problem Show Itself? When Might This Problem Occur? Potential Solutions End-to-End Testing How Can This Problem Show Itself? When Might This Problem Occur? Potential Solutions Limit scope of functional automated tests Use consumer-driven contracts Use automated release remediation and progressive delivery Continually refine your quality feedback cycles Global Versus Local Optimization How Can This Problem Show Itself? When Might This Problem Occur? Potential Solutions Robustness and Resiliency How Can This Problem Show Itself? When Might This Problem Occur? Potential Solutions Orphaned Services How Can This Problem Show Itself? When Might This Problem Occur? Potential Solutions Summary 6. Closing Words A. Bibliography B. Pattern Index Index O autorze: Sam Newman - jest technologiem w firmie ThoughtWorks, gdzie dzieli swój czas pomiędzy pomoc klientom z całego świata, a rolę architekta wewnętrznych systemów. Współpracował z różnymi firmami na całym świecie, zarówno w zakresie projektowania systemów, jak i innych operacji związanych z informatyką.