Download as PDF, PPTX
![@crichardson
Optimizing a monolith’s deployment pipeline
$ git pull
$./gradlew test
$ git push
! [rejected] ….
Use merge queue
Accelerate build/test:
• Incremental testing through DIP and ISP
• Parallelization/clustered builds
• Selective test execution
BUT if the application/team keeps growing
Then eventually the deployment pipeline = bottleneck
Module/New Feature → Service = faster deployment pipeline
IF
• Module is actively being developed
• Monolith is large
• Many teams](https://image.slidesharecdn.com/yow-london-2022-221130011727-e4ee1e19/75/YOW-London-Considering-Migrating-a-Monolith-to-Microservices-A-Dark-Energy-Dark-Matter-Perspective-27-2048.jpg)
Uploaded byChris Richardson
YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy, Dark Matter Perspective
The document discusses migrating from a monolithic architecture to microservices, emphasizing that the transition should be carefully considered based on organizational needs and architecture forces referred to as 'dark energy' and 'dark matter'. It highlights the benefits of microservices while also addressing potential complexities and costs involved in the transition. The presentation suggests making the most of existing monolithic applications before deciding to migrate, using dark energy to identify areas for improvement and service extraction.
More Related Content
Similar to YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy, Dark Matter Perspective
YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy, Dark Matter Perspective
- 1. @crichardson Migrating a monolithto microservices? A dark energy, dark matter perspective Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns @crichardson chris@chrisrichardson.net adopt.microservices.io Copyright © 2022. Chris Richardson Consulting, Inc. All rights reserved
- 2. @crichardson O V I D - 1 9 https://www.ft.com/content/f9356bdc-3102-11ea-a329-0bcf87a328f2 https://www.ft.com/content/3f498e64-1aa6-11ea-97df-cc63de1d73f4 https://techcrunch.com/2019/06/18/the-rise-of-the-gig-economy-helps-london-based-insurtech-zego-to-raise-42m/ Thriving in today’sworld Businesses must be nimble, agile and innovate faster Volatile Uncertain Complex Ambiguous
- 3. @crichardson Software is eatingthe world Business critical application You must deliver software rapidly, frequently, reliably and sustainably You Responsible for S/W VUCA
- 4. @crichardson Goal Your reality Measuredby DORA metrics + your monolith’s technology stack is out of date
- 5. @crichardson Adopting the microservice architecturewill make everything wonderful, right? Hint: it won’t
- 6. @crichardson Presentation goal Using the darkenergy and dark matter forces to decide whether to refactor a monolith to microservices
- 7. @crichardson About Chris http://adopt.microservices.io Late 80s2006 2008 2009 2012-
- 8. @crichardson Agenda Architecting for modernsoftware delivery Dark energy and dark matter: forces that drive the architecture Dark energy: encouraging decomposition Dark matter: resisting decomposition
- 9. @crichardson O V I D - 1 9 https://www.ft.com/content/f9356bdc-3102-11ea-a329-0bcf87a328f2 https://www.ft.com/content/3f498e64-1aa6-11ea-97df-cc63de1d73f4 https://techcrunch.com/2019/06/18/the-rise-of-the-gig-economy-helps-london-based-insurtech-zego-to-raise-42m/ The success triangle Process:DevOps/Continuous Delivery & Deployment Organization: Network of small, loosely coupled, product teams IT must deliver software rapidly, frequently, reliably and sustainably. Measured by the DORA metrics Businesses must be nimble, agile and innovate faster S/W VUCA Architecture: ??? Supports Supports
- 10. Required architectural quality attributes(.a.k.a. -ilities) DevOps Autonomous Teams Long-lived applications Testability Deployability Loose coupling Evolvability Enable incremental upgrades of technology stack
- 11. @crichardson Make the mostof the monolith Process: adopt DevOps and automate Organization: Restructure and increase autonomy Monolithic architecture: Modularize and modernize Success triangle
- 12. @crichardson If and onlyif that is insuf fi cient* then consider migrating to microservices *Large, complex applications developed by a (usually) large team that need to be delivered rapidly, frequently, and reliably
- 13. @crichardson On the otherhand: Improving the monolith can take a while THEREFORE Implement urgent new features as services now
- 14. @crichardson Strangler Fig Pattern:Incrementally refactoring a monolith to services 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 Stop/resume at any point When should you migrate? And, which parts?
- 15. @crichardson Agenda Architecting for modernsoftware delivery Dark energy and dark matter: forces that drive the architecture Dark energy: encouraging decomposition Dark matter: resisting decomposition
- 16. @crichardson How to de fi nean Architecture… Application ≪subdomain≫ Customer management ≪aggregate≫ Customer ≪subdomain≫ Order management ≪aggregate≫ Order createCustomer() createOrder() fi ndOrder() fi ndOrderHistory() System operations Distill Requirements The “requests” that the application implements Have SLOs Customer Team Order Team About Subdomains • Business capability/function/etc • Logical view: packages and classes • Team-sized • Loosely coupled (Conways law) 1 2 Functional requirements As a consumer I want to place an Order So that I can …. As a Restaurant I want to accept an Order So that I can …. Event storming Wireframe/UI mockups Available Restaurants Restaurant Menu System quality attributes • SLA: Reliability/Latency • Scalability • …
- 17. @crichardson Kitchen Service Delivery Service OrderService createOrder() … how to de fi ne an Architecture createOrder() <<subdomain>> Order Management Order System operations <<subdomain>> Order Management <<subdomain>> Kitchen Management <<subdomain>> Delivery Management <<subdomain>> Courier Management Group subdomains into services Application Collaboration Design collaborations for distributed operations createOrder() 3 Monolith or Microservices
- 18. @crichardson Grouping subdomains into components:together or separate? ≪subdomain≫ Customer ≪aggregate≫ Customer ≪subdomain≫ Order ≪aggregate≫ Order Attraction Repulsion Simple components Team-sized services Fast deployment pipeline … Dark energy: an anti- gravity that’s accelerating the expansion of the universe Dark matter: an invisible matter that has a gravitational effect on stars and galaxies. https://www.nasa.gov/feature/goddard/2020/new-hubble-data-explains-missing-dark-matter Simple, ef fi cient interactions Prefer ACID over BASE Minimize runtime coupling … https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html Generate systemOperation()
- 19. @crichardson Together or separate= Module vs. Service? FTGO Monolith Delivery Service FTGO Monolith Delivery Management createOrder() VS createOrder() Collaboration Order Management … Management Order Management … Management Dark Energy Dark Matter Bene fi ts Cost & Feasibility
- 20. @crichardson Agenda Architecting for modernsoftware delivery Dark energy and dark matter: forces that drive the architecture Dark energy: encouraging decomposition Dark matter: resisting decomposition
- 21. @crichardson Repulsive forces subdomains indifferent services https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html = reasons to migrate a module into a service Service Service «Subdomain» A «Aggregate» X «Subdomain» B «Aggregate» Y Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Segregate by characteristics Repulsive dark energy forces
- 22. @crichardson Simpler components/services Service Service Service Subdomain A Subdomain A Subdomain B Subdomain B More complexservice Simpler services: easier to understand, develop, test, … versus
- 23. Simplifying a monolith Modularizingthe monolith helps reduce complexity Developer can focus on their module BUT Complexity ∝Size Github Repository «Gradle Project» FtgoApplication «Gradle Subproject» main main «Gradle Subproject» orders orders.web «Gradle Subproject» customerAPI orders. domain «Gradle Subproject» customers customers. persistence orders. persistence Customer team Order team customers. domain customers. web customers. api Module/New Feature → Service = simpler development IF • Module is actively being developed • Monolith is large
- 24. @crichardson Team autonomy =service per team Service Service Service Subdomain A Subdomain A Subdomain B Subdomain B Coordination required Build, test and deploy independently vs. Team A Team B Team A Team B
- 25. Monoliths and teamautonomy Modularization helps BUT Single code base Autonomy ∝ 1/ # developers Github Repository «Gradle Project» FtgoApplication «Gradle Subproject» main main «Gradle Subproject» orders orders.web «Gradle Subproject» customerAPI orders. domain «Gradle Subproject» customers customers. persistence orders. persistence Deployment pipeline Production FTGO Application Executable JAR customers. domain customers. web customers. api Module/New Feature → Service = increased autonomy IF • Module is actively being developed • Many teams
- 26. @crichardson Fast deployment pipeline @mipsytipsy https://speakerdeck.com/charity/cd?slide=17 Service Subdomain Subdomain Service Subdomain Shorter leadtime Simpler build Longer lead time More complex build* * Parallelizing building/testing partially helps Service Subdomain vs.
- 27. @crichardson Optimizing a monolith’sdeployment pipeline $ git pull $./gradlew test $ git push ! [rejected] …. Use merge queue Accelerate build/test: • Incremental testing through DIP and ISP • Parallelization/clustered builds • Selective test execution BUT if the application/team keeps growing Then eventually the deployment pipeline = bottleneck Module/New Feature → Service = faster deployment pipeline IF • Module is actively being developed • Monolith is large • Many teams
- 28. @crichardson Support multiple technology stacks Service Python Service Java Service JVM Subdomain A Subdomain A Subdomain B Subdomain B Singletechnology stack Upgrade together Separate technology stacks Right tool for the job Upgrade independently Experiment easily versus
- 29. @crichardson Monolith = singletechnology stack Single class path unless using exotic technology, eg. Layrry Single version of each dependency => big bang upgrades No opportunity to experiment No possibility of using non-JVM technologies, e.g. Python Module/New Feature → Service = multiple technology stacks
- 30. @crichardson Separate subdomains by characteristics Subdomaincharacteristic Issue Resource requirements Cost-effective, scalability Regulations, e.g. SaMD/ PCI DevOps vs. Slower regulated process Business criticality/tier Maximize availability Security, e.g. PII, … Improve security DDD core/supporting/ generic Focus on being competitive
- 31. @crichardson Cost effective scaling Service Service Service Subdomain A Subdomain A Subdomain B Subdomain B versus CPUMEM GPU Scale together • Wasteful • Costly CPU MEM GPU Scale separately • Ef fi cient • Cheaper Load Load Load Load EC2: p4d.24xlarge EC2: p4d.24xlarge EC2: m5.24xlarge 8x cost!
- 32. @crichardson Example: Segregate bybusiness criticality Service Service Service Payment Processing Payment Processing Merchant management Merchant management Shared infrastructure Shared code base Risk of interference Separate infrastructure Separate code base Isolated vs. chargeCard() 2.9% + 30c/ request Revenue loss and penalties chargeCard() Critical Important
- 33. @crichardson Multiple “deployments” canaddress some requirements FTGO Monolith FTGO Monolith Router chargeCard() ….() SPRING_PROFILES_ACTIVE=…. SPRING_PROFILES_ACTIVE=…. Request BUT not others: • single code base • …. • Scalability • Availability • … Module/New Feature → Service = Improves architecture via separation
- 34. @crichardson Some parts ofyour monolith will bene fi t more from microservices e.g. actively being developed => Using dark energy to identify candidate services
- 35. @crichardson Data science team (Not“hardcore” devs) ML-based Fraud detection Service E-Commerce Monolith Develops Faster deployment pipeline Python technology stack Simpli fi ed development experience Improved autonomy
- 36. @crichardson Agenda Architecting for modernsoftware delivery Dark energy and dark matter: forces that drive the architecture Dark energy: encouraging decomposition Dark matter: resisting decomposition
- 37. @crichardson Attractive forces subdomains insame service https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html Subdomain A «Aggregate» X Subdomain B «Aggregate» Y Service A Service B Simple interactions Efficient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Generates SystemOperation() Collaboration
- 38. @crichardson Simple interactions Create Order() Service Subdomain A Subdomain B Service B ServiceA Subdomain A Subdomain B Create Order() Complex distributed operation Simple local operation: easier to understand, troubleshoot, … vs.
- 39. @crichardson Impact of extractingservices on complexity FTGO Monolith Delivery Service FTGO Monolith Delivery Management createOrder() … createOrder() … Collaboration Order Management … Management Order Management … Management Might increase complexity
- 40. @crichardson Ef fi cient interactions Create Order() Service Subdomain A Subdomain B Service B ServiceA Subdomain A Subdomain B Create Order() Network latency, limited bandwidth In-memory, fast! vs. Must satisfy SLOs
- 41. @crichardson Impact of extractingservices on ef fi ciency FTGO Monolith Delivery Service FTGO Monolith Delivery Management createOrder() … createOrder() … Collaboration Order Management … Management Order Management … Management Might be too inef fi cient
- 42. @crichardson Prefer ACID overBASE System Operation() Service Subdomain A Subdomain B Service B Service A Subdomain A Subdomain B System Operation() Distributed, eventually consistent transaction Simple, Local ACID transaction vs. ACID txn ACID txn ACID txn
- 43. @crichardson Impact of extractingservices on transactions FTGO Monolith Delivery Service FTGO Monolith Delivery Management createOrder() … createOrder() … Saga Order Management … Management Order Management … Management Might need compensating transactions = complex changes to monolith 1. createOrder() 2. createDelivery() FAILS 2. rejectOrder()
- 44. @crichardson Minimize runtime coupling System Operation() Service Subdomain A Subdomain B ServiceB Service A Subdomain A Subdomain B System Operation() Risk of runtime coupling No runtime coupling: higher availability, lower latency vs. Must satisfy SLOs
- 45. @crichardson Impact of extractingservices on runtime coupling FTGO Monolith Delivery Service FTGO Monolith Delivery Management createOrder() … createOrder() … Collaboration Order Management … Management Order Management … Management Might have excessive runtime coupling
- 46. @crichardson Minimize design timecoupling Order Subdomain Customer Subdomain reserveCredit() createOrder() Customer Order Design-time coupling Minimize with careful design BUT You can’t always eliminate it Risk of lock step changes API Risk proportional to: • API instability • API complexity • …
- 47. @crichardson Impact of extractingservices on design-time coupling Monolith and new service might have excessive design-time coupling BUT Experience with monolith = domain expertise = MonolithFirst Increases likelihood of designing services with stable API Reduced risk of accidentally creating design-time coupled services
- 48. @crichardson Consequences of darkmatter forces FTGO Monolith Delivery Service FTGO Monolith Delivery Management createOrder() … createOrder() … Collaboration Order Management … Management Order Management … Management Might not resolve dark matter forces: Infeasible architecture Prefer ACID over BASE: Might need expensive to implement compensating transactions in monolith
- 49. @crichardson Summary Don’t automatically assumeyou need microservices: Make the most of your monolith Improve your process and organization BUT An application/organization can outgrow its monolithic architecture THEREFORE Incrementally refactor to microservices Dark energy forces help identify candidate services Dark matter forces can make extracting a service infeasible or expensive https://www.nasa.gov/feature/goddard/2019/nasa-s-james-webb-space-telescope-has-been-assembled-for-the- fi rst-time Process Organization Architecture
- 50.