O slideshow foi denunciado.
Seu SlideShare está sendo baixado. ×

YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy, Dark Matter Perspective

Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Anúncio
Carregando em…3
×

Confira estes a seguir

1 de 50 Anúncio

YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy, Dark Matter Perspective

Baixar para ler offline

This is a talk I gave at YOW! London 2022.

Let's imagine that you are responsible for an aging monolithic application that's critical to your business. Sadly, getting changes into production is a painful ordeal that regularly causes outages. And to make matters worse, the application's technology stack is growing increasingly obsolete. Neither the business nor the developers are happy. You need to modernize your application and have read about the benefits of microservices. But is the microservice architecture a good choice for your application?

In this presentation, I describe the dark energy and dark matter forces (a.k.a. concerns) that you must consider when deciding between the monolithic and microservice architectural styles. You will learn about how well each architectural style resolves each of these forces. I describe how to evaluate the relative importance of each of these forces to your application. You will learn how to use the results of this evaluation to decide whether to migrate to the microservice architecture.

This is a talk I gave at YOW! London 2022.

Let's imagine that you are responsible for an aging monolithic application that's critical to your business. Sadly, getting changes into production is a painful ordeal that regularly causes outages. And to make matters worse, the application's technology stack is growing increasingly obsolete. Neither the business nor the developers are happy. You need to modernize your application and have read about the benefits of microservices. But is the microservice architecture a good choice for your application?

In this presentation, I describe the dark energy and dark matter forces (a.k.a. concerns) that you must consider when deciding between the monolithic and microservice architectural styles. You will learn about how well each architectural style resolves each of these forces. I describe how to evaluate the relative importance of each of these forces to your application. You will learn how to use the results of this evaluation to decide whether to migrate to the microservice architecture.

Anúncio
Anúncio

Mais Conteúdo rRelacionado

Mais de Chris Richardson (20)

Mais recentes (20)

Anúncio

YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy, Dark Matter Perspective

  1. 1. @crichardson Migrating a monolith to 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. 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’s world Businesses must be nimble, agile and innovate faster Volatile Uncertain Complex Ambiguous
  3. 3. @crichardson Software is eating the world Business critical application You must deliver software rapidly, frequently, reliably and sustainably You Responsible for S/W VUCA
  4. 4. @crichardson Goal Your reality Measured by DORA metrics + your monolith’s technology stack is out of date
  5. 5. @crichardson Adopting the microservice architecture will make everything wonderful, right? Hint: it won’t
  6. 6. @crichardson Presentation goal Using the dark energy and dark matter forces to decide whether to refactor a monolith to microservices
  7. 7. @crichardson About Chris http://adopt.microservices.io Late 80s 2006 2008 2009 2012-
  8. 8. @crichardson Agenda Architecting for modern software delivery Dark energy and dark matter: forces that drive the architecture Dark energy: encouraging decomposition Dark matter: resisting decomposition
  9. 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. 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. 11. @crichardson Make the most of the monolith Process: adopt DevOps and automate Organization: Restructure and increase autonomy Monolithic architecture: Modularize and modernize Success triangle
  12. 12. @crichardson If and only if 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. 13. @crichardson On the other hand: Improving the monolith can take a while THEREFORE Implement urgent new features as services now
  14. 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. 15. @crichardson Agenda Architecting for modern software delivery Dark energy and dark matter: forces that drive the architecture Dark energy: encouraging decomposition Dark matter: resisting decomposition
  16. 16. @crichardson How to de fi ne an 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. 17. @crichardson Kitchen Service Delivery Service Order Service 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. 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. 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. 20. @crichardson Agenda Architecting for modern software delivery Dark energy and dark matter: forces that drive the architecture Dark energy: encouraging decomposition Dark matter: resisting decomposition
  21. 21. @crichardson Repulsive forces subdomains in different 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. 22. @crichardson Simpler components/services Service Service Service Subdomain A Subdomain A Subdomain B Subdomain B More complex service Simpler services: easier to understand, develop, test, … versus
  23. 23. Simplifying a monolith Modularizing the 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. 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. 25. Monoliths and team autonomy 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. 26. @crichardson Fast deployment pipeline @mipsytipsy https://speakerdeck.com/charity/cd?slide=17 Service Subdomain Subdomain Service Subdomain Shorter lead time Simpler build Longer lead time More complex build* * Parallelizing building/testing partially helps Service Subdomain vs.
  27. 27. @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
  28. 28. @crichardson Support multiple technology stacks Service Python Service Java Service JVM Subdomain A Subdomain A Subdomain B Subdomain B Single technology stack Upgrade together Separate technology stacks Right tool for the job Upgrade independently Experiment easily versus
  29. 29. @crichardson Monolith = single technology 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. 30. @crichardson Separate subdomains by characteristics Subdomain characteristic 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. 31. @crichardson Cost effective scaling Service Service Service Subdomain A Subdomain A Subdomain B Subdomain B versus CPU MEM 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. 32. @crichardson Example: Segregate by business 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. 33. @crichardson Multiple “deployments” can address 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. 34. @crichardson Some parts of your monolith will bene fi t more from microservices e.g. actively being developed => Using dark energy to identify candidate services
  35. 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. 36. @crichardson Agenda Architecting for modern software delivery Dark energy and dark matter: forces that drive the architecture Dark energy: encouraging decomposition Dark matter: resisting decomposition
  37. 37. @crichardson Attractive forces subdomains in same 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. 38. @crichardson Simple interactions Create Order() Service Subdomain A Subdomain B Service B Service A Subdomain A Subdomain B Create Order() Complex distributed operation Simple local operation: easier to understand, troubleshoot, … vs.
  39. 39. @crichardson Impact of extracting services on complexity FTGO Monolith Delivery Service FTGO Monolith Delivery Management createOrder() … createOrder() … Collaboration Order Management … Management Order Management … Management Might increase complexity
  40. 40. @crichardson Ef fi cient interactions Create Order() Service Subdomain A Subdomain B Service B Service A Subdomain A Subdomain B Create Order() Network latency, limited bandwidth In-memory, fast! vs. Must satisfy SLOs
  41. 41. @crichardson Impact of extracting services 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. 42. @crichardson Prefer ACID over BASE 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. 43. @crichardson Impact of extracting services 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. 44. @crichardson Minimize runtime coupling System Operation() Service Subdomain A Subdomain B Service B Service A Subdomain A Subdomain B System Operation() Risk of runtime coupling No runtime coupling: higher availability, lower latency vs. Must satisfy SLOs
  45. 45. @crichardson Impact of extracting services 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. 46. @crichardson Minimize design time coupling 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. 47. @crichardson Impact of extracting services 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. 48. @crichardson Consequences of dark matter 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. 49. @crichardson Summary Don’t automatically assume you 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. 50. @crichardson @crichardson chris@chrisrichardson.net adopt.microservices.io Questions?

×