Oracle CodeOne 2019: Decompose Your Monolith: Strategies for Migrating to Microservices
•
5 likes•9,181 views
A typical mission-critical enterprise application is a large, complex monolith developed by a 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? This session describes when you should consider migrating to microservices. You will learn strategies for migrating a monolith application to a microservice architecture. The presentation explains how to implement new functionality as services, and you will also 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 Oracle CodeOne 2019: Decompose Your Monolith: Strategies for Migrating to Microservices
Similar to Oracle CodeOne 2019: Decompose Your Monolith: Strategies for Migrating to Microservices (20)
More from Chris Richardson
More from Chris Richardson (18)
Recently uploaded
Recently uploaded (20)
Oracle CodeOne 2019: Decompose Your Monolith: Strategies for Migrating to Microservices
- 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 https://adopt.microservices.io Copyright © 2019. 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 ctworaclecodeone19
- 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
- 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
- 12. @crichardson When to migrate to microservices: DON”T! 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 …
- 13. @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
- 14. @crichardson How do you decompose your big, scary monolithic application? Monolith Service? Microservice architecture Service Service Service
- 15. @crichardson According to Randy Shoup: “As Martin Fowler likes to say, the only thing a Big Bang rewrite guarantees is a Big Bang!” http://www.randyshoup.com/evolutionary-architecture
- 18. @crichardson
- 19. @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
- 20. @crichardson Module Strangling the monolith: reroute requests to services Monolith Service API Gateway Request Monolith Module Request
- 21. @crichardson Agenda Why microservices? Overview of refactoring a monolith Implementing new features as services Extracting modules into services
- 22. @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!
- 23. @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
- 24. @crichardson Service Monolith data integration glue: API invocation Monolith Service Monolithic database Service database Invokes Command/ Query
- 25. @crichardson Service Monolith data integration glue: replicate data for reading Monolith Service Monolithic database Service database Application events DB replicationTables Replica CDC Events
- 26. @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
- 27. @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
- 28. @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
- 29. 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
- 30. @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
- 31. @crichardson Agenda Why microservices? Overview of refactoring a monolith Implementing new features as services Extracting modules into services
- 32. @crichardson Module service ... Monolithic database Module’s tables Module Monolith Ext. API Including slices of tables
- 33. @crichardson Define a two way “remotable” interface Monolithic database Module’s tables Module Untangle dependencies Monolith Ext. API Modifying the monolith is tricky
- 34. @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
- 35. @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
- 36. @crichardson ... Module service Monolith Service Monolithic database Module Database API Gateway Request Existing code or rewrite Ext. API Bidirectional integration glue
- 37. @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
- 38. @crichardson What to extract? Have the ideal microservice architecture in mind Limited time-boxed architecture definition effort But be prepared to revise as you learn more Start with the modules that would give you the greatest ROI: Solves a significant problem Velocity frequently updated Scalability Conflicting resource requirements
- 39. @crichardson Example: Extracting delivery management from the FTGO monolith https://microservices.io/refactoring/
- 40. @crichardson AS-IS architecture: tangled code FTGO <<module>> Order and DeliveryManagement <<entity>> Order ORDER_ID STATE … DELIVERY_STATE COURIER_ID … … … … … Consumer Courier ORDER table noteAvailable() notePickedUp noteDelivered() … Tangled code and data
- 41. @crichardson AS-IS: tangled code Order deliveryTime Restaurant address … Courier address availability … Plan Action type Line Item Address delivery Delivery Management
- 42. @crichardson TO-BE design Order deliveryTime Restaurant Courier availability … Plan Action type Line Item Address delivery Courier address availability … Delivery deliveryTime FTGO monolith Delivery Service How to sync with Order? Owned by Monolith! Inter-service reference!!!
- 43. @crichardson FTGO monolith Delivery Service integration Delivery Service Restaurant Courier availability … Delivery deliveryTime schedule() reschedule() cancel() “Replicas” FTGO monolith Data integration glue Client API
- 44. @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
- 45. @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()
- 46. @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() Split ext. API Integration API Shared table
- 47. @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
- 48. @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
- 49. @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
- 50. @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(…) …
- 51. @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
- 52. @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
- 53. @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
- 54. @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
- 55. @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
- 56. @crichardson @crichardson chris@chrisrichardson.net http://adopt.microservices.io Questions? 40% discount with code ctworaclecodeone19