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

3. @crichardson About Chris http://adopt.microservices.io

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

12. @crichardson When to migrate to the Microservice Architecture?

13. @crichardson DON”T! Anti-pattern: Magic pixie dust

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 insufﬁcient* 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

19. @crichardson Best done incrementally!

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 deﬁnition 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

29. @crichardson Cost: couplingModule Module Module Increasing Cost

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. Beneﬁt Beneﬁt 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

34. @crichardson Let’s imagine you want to implement a signiﬁcant new feature…. The Law of Holes: "if you ﬁnd 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 Beneﬁts Drawbacks API call to monolith Simple Works for writes and reads Doesn’t efﬁciently support complex queries Replicate data to service Supports complex queries Only for reads Cost/complexity of replication

39. @crichardson Data replication options Option Beneﬁts 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

41. @crichardson Module service ... Monolithic database Module’s tables Module Monolith Ext. API Including slices of tables

42. @crichardson Deﬁne 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

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: deﬁne separate DB schema for delivery management within the monolith 3.Deﬁne 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 Deﬁning 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 - Deﬁne 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

62. @crichardson FTGO Delayed delivery service As a workaround for a mediocre courier scheduling algorithm that is taking too long to ﬁx…… 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 notiﬁcations 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 beneﬁt

66. @crichardson @crichardson chris@chrisrichardson.net http://adopt.microservices.io Questions? 40% discount with code mtptide20