Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Decompose your monolith: strategies for migrating to microservices (Tide)

368 views

Published on

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.

Published in: Technology
  • Be the first to comment

Decompose your monolith: strategies for migrating to microservices (Tide)

  1. 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. 2. @crichardson Presentation goal How to incrementally refactor a monolithic application to microservices
  3. 3. @crichardson About Chris http://adopt.microservices.io
  4. 4. @crichardson About Chris https://microservices.io/book 40% discount with code mtptide20
  5. 5. About Chris: microservices.io Microservices pattern language Articles Example code Microservices Assessment Platform
  6. 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. 7. @crichardson + Marketplace is volatile, uncertain, complex and ambiguous + Businesses must innovate faster Deliver software rapidly, frequently and reliably Software
  8. 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. 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. 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. 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. 12. @crichardson When to migrate to the Microservice Architecture?
  13. 13. @crichardson DON”T! Anti-pattern: Magic pixie dust
  14. 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. 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. 16. @crichardson How do you decompose your big, scary monolithic application? Monolith Service? Microservice architecture Service Service Service
  17. 17. @crichardson This is a variant of application modernization
  18. 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
  19. 19. @crichardson Best done incrementally!
  20. 20. @crichardson Strangler Application http://www.martinfowler.com/bliki/StranglerApplication.html Incrementally migrate functionality from existing application to new (strangler) application
  21. 21. @crichardson
  22. 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. 23. @crichardson Module Iteratively: Module => Service Monolith Service API Gateway Request Monolith Module Request
  24. 24. @crichardson Iteratively: New feature = Service Monolith Service API Gateway Request
  25. 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. 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. 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. 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
  29. 29. @crichardson Cost: couplingModule Module Module Increasing Cost
  30. 30. @crichardson Cost: transaction management/Sagas T1 C1 T2 T3 Monolith Compensating transaction T1 T2 T3 Monolith Service Increasing Cost Service
  31. 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. 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. 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. 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. 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. 36. @crichardson Service Monolith data integration glue: API invocation Monolith Service Monolithic database Service database Invokes Command/ Query
  37. 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. 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. 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. 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. 41. @crichardson Module service ... Monolithic database Module’s tables Module Monolith Ext. API Including slices of tables
  42. 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. 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. 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. 45. @crichardson ... Module service Monolith Service Monolithic database Module Database API Gateway Request Existing code or rewrite Ext. API Bidirectional integration glue
  46. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  66. 66. @crichardson @crichardson chris@chrisrichardson.net http://adopt.microservices.io Questions? 40% discount with code mtptide20

×