Decompose your monolith: strategies for migrating to microservices (Tide)
•
1 like•500 views
This is a presentation that I gave at Tide.co, London - January 2020 A typical mission-critical enterprise application is a large, complex monolith developed by large team. Software delivery is usually slow, and the team struggles to keep up with the demands of the business. Consequently, many enterprise applications are good candidates to be migrated to the microservice architecture. But how do you know whether it makes sense to migrate to microservices? And, how to get there? In this presentation, I describe when you should consider migrating to microservices. You will learn strategies for migrating a monolith application to a microservice architecture. I explain how to implement new functionality as services. You will learn how to incrementally break apart a monolith one service at a time.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Decompose your monolith: strategies for migrating to microservices (Tide)
Similar to Decompose your monolith: strategies for migrating to microservices (Tide) (20)
More from Chris Richardson
More from Chris Richardson (18)
Recently uploaded
Recently uploaded (20)
Decompose your monolith: strategies for migrating to microservices (Tide)
- 1. @crichardson Decompose your monolith: strategies for migrating to microservices Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns @crichardson chris@chrisrichardson.net http://adopt.microservices.io Copyright © 2020. Chris Richardson Consulting, Inc. All rights reserved
- 2. @crichardson Presentation goal How to incrementally refactor a monolithic application to microservices
- 4. @crichardson About Chris https://microservices.io/book 40% discount with code mtptide20
- 5. About Chris: microservices.io Microservices pattern language Articles Example code Microservices Assessment Platform
- 6. @crichardson Agenda Why microservices? Overview of refactoring a monolith Implementing new features as services Extracting modules into services Example: extracting the Delivery Service Example: implementing the Delayed Delivery Service
- 7. @crichardson + Marketplace is volatile, uncertain, complex and ambiguous + Businesses must innovate faster Deliver software rapidly, frequently and reliably Software
- 8. @crichardson Monolithic architecture: -ilities decline over time Time Maintainability Testability Deployability Modularity Evolvability Size/ Complexity -ilities required to be competitive Risk of disruption
- 9. The microservice architecture is an architectural style that structures an application as a set of services* Each microservice is: • highly maintainable and testable • loosely coupled • independently deployable • organized around business capabilities • owned by a small team *Start with one service per team until it becomes a problem
- 10. @crichardson Process: Lean + DevOps/Continuous Delivery & Deployment Organization: Small, autonomous, product teams Architecture: microservices Testability Deployability Modularity Modularity Evolvability Maintainability Rapidly, frequently and reliably delivery of changes to long-lived applications
- 11. @crichardson Agenda Why microservices? Overview of refactoring a monolith Implementing new features as services Extracting modules into services Example: extracting the Delivery Service Example: implementing the Delayed Delivery Service
- 12. @crichardson When to migrate to the Microservice Architecture?
- 14. @crichardson Make the most of the monolithic architecture The monolithic architecture is not an anti-pattern If software delivery is slow Optimize development process Improve deployment pipeline = more automation Improve team autonomy Modularize the monolith Eliminate hand-offs and create cross functional teams If technology stack is obsolete modernize to a new monolith …
- 15. @crichardson If and only if that is insufficient* then consider migrating to microservices *Large, complex applications developed by a (usually) large team that need to be delivered rapidly, frequently, and reliably
- 16. @crichardson How do you decompose your big, scary monolithic application? Monolith Service? Microservice architecture Service Service Service
- 17. @crichardson This is a variant of application modernization
- 18. @crichardson According to Randy Shoup: “As Martin Fowler likes to say, the only thing a Big Bang rewrite guarantees is a Big Bang!” Via @randyshoup
- 20. @crichardson Strangler Application http://www.martinfowler.com/bliki/StranglerApplication.html Incrementally migrate functionality from existing application to new (strangler) application
- 21. @crichardson
- 22. @crichardson Strangling the monolith Monolith Time Monolith Service Monolith Service Service Monolith Service Service Service Service …. Monolith Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service …. Strangler application The strangler application grows larger over time The monolith shrinks over time Service Service Service Service Service Service Service Service New features
- 23. @crichardson Module Iteratively: Module => Service Monolith Service API Gateway Request Monolith Module Request
- 24. @crichardson Iteratively: New feature = Service Monolith Service API Gateway Request
- 25. @crichardson Measuring success Success != Number of Microservices Improved metrics: Reduced lead time Increased deployment frequency Reduced changed failure rate Improvements in other -ilities … Anti-pattern: Microservices as the goal
- 26. @crichardson Repeat extracting services until: • Eliminated the monolith • Solved software delivery problems • Higher priority work Monolith Time Monolith Service Monolith Service Service Monolith Service Service Service Service …. Monolith Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service …. Strangler application The strangler application grows larger over time The monolith shrinks over time Years
- 27. @crichardson What to extract? Have the ideal microservice architecture in mind Limited timeboxed architecture definition effort But be prepared to revise as you learn more Start with the modules that would give you the greatest return on investment (ROI)
- 28. Cost vs. Benefit of extraction Benefit Solves a significant problem Velocity frequently updated Scalability Conflicting resource requirements … Cost Cost of changing the monolith and adapting/ rewriting module Difficulty in decoupling/ breaking dependencies Need to participate in sagas/compensating transactions
- 30. @crichardson Cost: transaction management/Sagas T1 C1 T2 T3 Monolith Compensating transaction T1 T2 T3 Monolith Service Increasing Cost Service
- 31. @crichardson Extracting a service: cost vs. Benefit Benefit of extraction Ease of extraction High HighLow Low Module B Module A Module CModule D Module E
- 32. @crichardson To learn more… https://microservices.io/book 40% discount with code mtptide20 Chapter 13https://microservices.io/refactoring/index.html https://github.com/microservices-patterns/ftgo-monolith
- 33. @crichardson Agenda Why microservices? Overview of refactoring a monolith Implementing new features as services Extracting modules into services Example: extracting the Delivery Service Example: implementing the Delayed Delivery Service
- 34. @crichardson Let’s imagine you want to implement a significant new feature…. The Law of Holes: "if you find yourself in a hole, stop digging" (https://en.m.wikipedia.org/wiki/Law_of_holes) Stop making the monolith larger!
- 35. @crichardson Implement new functionality as a service Monolith Service Data integration glue API Gateway Request Monolithic database Service database Code in service/monolith that enables service to access monolith’s data Pristine new service
- 36. @crichardson Service Monolith data integration glue: API invocation Monolith Service Monolithic database Service database Invokes Command/ Query
- 37. @crichardson Service Monolith data integration glue: replicate data for reading Monolith Service Monolithic database Service database Application events DB replicationTables Replica CDC Events
- 38. @crichardson Service Monolith data access options Option Benefits Drawbacks API call to monolith Simple Works for writes and reads Doesn’t efficiently support complex queries Replicate data to service Supports complex queries Only for reads Cost/complexity of replication
- 39. @crichardson Data replication options Option Benefits Drawbacks Application events Easy to publish meaningful events Decoupled Requires code changes in monolith Eventual consistency Change data capture CRUD Events No code changes in monolith Decoupled Publishing non-CRUD event is tricky Eventual consistency Triggers that publish CRUD events Simple No code changes in monolith Decoupled Triggers = yuck Publishing non-CRUD event is tricky Eventual consistency Triggers that update target DB Simple No code changes in monolith ACID consistency Triggers = yuck Coupled to target DB Other DB replication mechanism, e.g. OGG Simple No code changes in monolith Coupled to target DB Eventual consistency
- 40. @crichardson Agenda Why microservices? Overview of refactoring a monolith Implementing new features as services Extracting modules into services Example: extracting the Delivery Service Example: implementing the Delayed Delivery Service
- 41. @crichardson Module service ... Monolithic database Module’s tables Module Monolith Ext. API Including slices of tables
- 42. @crichardson Define a two way “remotable” interface Monolithic database Module’s tables Module Untangle dependencies Monolith Ext. API Modifying the monolith is tricky
- 43. @crichardson Incrementally modify monolith to invoke module via new API* Module Module All writes - module/service owns its data Ideally all reads - but can replicate changes back *Branch by abstraction pattern
- 44. @crichardson Replicating data to reduce scope of refactoring ORDER_ID STATE … DELIVERY_STATE COURIER_ID … … … … … ORDER_ID STATE … STATE COURIER_ID … … … … … ID … COURIER_ID … ORDERS table ORDERS table DELIVERY table Replicate back, e.g. trigger Read-only replica Extract delivery service Delivery management
- 45. @crichardson ... Module service Monolith Service Monolithic database Module Database API Gateway Request Existing code or rewrite Ext. API Bidirectional integration glue
- 46. @crichardson Agenda Why microservices? Overview of refactoring a monolith Implementing new features as services Extracting modules into services Example: extracting the Delivery Service Example: implementing the Delayed Delivery Service
- 47. @crichardson AS-IS architecture FTGO <<module>> Order and Delivery Management <<entity>> Order ORDER_ID STATE … DELIVERY_STATE COURIER_ID … … … … … Consumer Courier ORDER table noteAvailable() notePickedUp noteDelivered() … Tangled code and data Want to extract
- 48. @crichardson AS-IS: tangled code Order deliveryTime Restaurant address … Courier address availability … Plan Action type Line Item Address delivery Delivery Management assigned courier delivery
- 49. @crichardson TO-BE design Delivery Service Restaurant Courier availability … Delivery deliveryTime DeliveryService schedule() reschedule() cancel() “Replicas” FTGO monolith Data integration glue Order Management API Plan Action type
- 50. @crichardson AS-IS TO-BE: Overview of extracting the Delivery Service 1. Split the code: convert delivery management code into a module within the monolith 2.Split the database: define separate DB schema for delivery management within the monolith 3.Define and deploy Delivery Service 4.Use the Delivery Service 5.Remove old code from monolith Commit and deploy changes after each step
- 51. @crichardson FTGO <<module>> Order Management <<module>> Delivery Management <<entity>> Order ORDER_ID STATE … DELIVERY_STATE COURIER_ID … … … … … Consumer Courier schedule() ORDER table <<entity>> Delivery Step #1 - Separate code cancel() reschedule()
- 52. @crichardson Delivery Mgmt Module Restaurant Courier availability location … Delivery deliveryTime Delivery Service schedule() reschedule() cancel() Delivery Controller updateCourierLocation() updateCourierAvailability() Order Service Order Mgmt Module Order Order table Courier Restaurant Mapped to original tables Order Controller updateCourierLocation() updateCourierAvailability() External API Integration API Shared table
- 53. @crichardson FTGO <<module>> Order Management <<module>> Delivery Management <<entity>> Order Consumer Courier schedule() <<entity>> Delivery ORDER_ID STATE … STATE COURIER_ID … … … … … ID … DELIVERY tableORDER table Extract table Step #2 - Separate data COURIER_ID … Replicate back! Creates Delivery
- 54. @crichardson Defining the DELIVERY table create table ftgo_delivery.delivery (…) select …subset of columns… from ftgo.orders where assigned_courier_id is not null; CREATE TRIGGER assigned_courier_id_updated AFTER UPDATE ON delivery FOR EACH ROW BEGIN UPDATE ftgo.orders SET assigned_courier_id = NEW.assigned_courier_id where id = NEW.id; END;; Replicate assigned_courier back to ORDERS table
- 55. @crichardson Delivery ServiceFTGO But it’s not just the DELIVERY table Courier Id Name Availability Courier Id Name Availability … CourierActions … CourierActions …. Restaurant Id Name Address Restaurant Id Name Address … Sync
- 56. @crichardson Replicating the RESTAURANT table create table ftgo_delivery.restaurants select …subset of columns… from ftgo.restaurants CREATE TRIGGER restaurant_created AFTER INSERT ON ftgo.restaurants FOR EACH ROW BEGIN INSERT INTO ftgo_delivery_service.restaurants(…) …
- 57. @crichardson FTGO <<module>> Order Management <<module>> Delivery Management <<entity>> Order Consumer Courier schedule() <<entity>> Delivery ORDER_ID STATE … STATE COURIER_ID… … … … … ID … DELIVERY table ORDER table Delivery Service <<module>> Delivery Management <<entity>> Delivery Step #3 - Define and deploy new service
- 58. @crichardson FTGO <<module>> Order Management <<module>> Delivery Management <<entity>> Order Consumer Courier schedule() <<entity>> Delivery ORDER_ID STATE … STATE COURIER_ID … … … … … ID … DELIVERY tableORDER table Delivery Service <<module>> Delivery Management <<entity>> Delivery Step #4 - Use service
- 59. @crichardson Integration using asynchronous messaging Delivery Service Delivery Service schedule() reschedule() cancel() Delivery Controller Order Service FTGO Order Controller Delivery Service Proxy schedule() … Command Handlers Schedule command message Message channel
- 60. @crichardson FTGO <<module>> Order Management <<entity>> Order Consumer Courier schedule() Delivery Service <<module>> Delivery Management <<entity>> Delivery STATE COURIER_ID … … ID … DELIVERY table ORDER_ID STATE … … … … ORDER table Step #5 - delete old code
- 61. @crichardson Agenda Why microservices? Overview of refactoring a monolith Implementing new features as services Extracting modules into services Example: extracting the Delivery Service Example: implementing the Delayed Delivery Service
- 62. @crichardson FTGO Delayed delivery service As a workaround for a mediocre courier scheduling algorithm that is taking too long to fix…… Improve customer satisfaction by proactively notifying customers (and customer experience) that their order won’t be delivered on time
- 63. FTGO Delayed delivery service Periodically looks for orders that won’t be delivered on time Not picked up and restaurant closed Courier delayed … Notifies consumer and CRM system getDelayedOrders() Notification Service CRM system Send apology notification create case REST API ??? Delayed Order Service «stereotype» Order «entity» Restaurant «entity» OpeningHours «entity» Notification API gateway «repository» Customer ContactInfo Repository Monolith ??? REST API «Service» DelayedDelivery Service Integration glue Need to design
- 64. @crichardson Delayed delivery service: data integration strategies Usage How Orders “complex” query to determine whether delivery will be delayed ReplicateRestaurants Courier Consumers Contact info for notifications Query via API
- 65. @crichardson Summary The microservice architecture enables the rapid, frequent and reliable delivery of changes to long-lived applications Incrementally migrate to microservices when you have outgrown your monolith Implement new features as services Extract modules into service Prioritize extracting modules that give the greatest benefit