Decompose your monolith: Six principles for refactoring a monolith to microservices
8 likes22,806 views
The document outlines six principles for refactoring a monolith to microservices, emphasizing the importance of optimizing the existing monolith before making the transition. Key strategies include incremental migration, focusing on high-value modules first, and defining correct service boundaries to maintain system availability. Success is measured by improved software delivery metrics such as reduced lead time and increased deployment frequency.
Decompose your monolith: Six principles for refactoring a monolith to microservices
- 1. @crichardson Decompose your monolith: Six principles for refactoring a monolith to microservices Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns @crichardson [email protected] http://adopt.microservices.io Copyright © 2020. Chris Richardson Consulting, Inc. All rights reserved
- 3. @crichardson Agenda 1. Make the most of your monolith 2. Adopt microservices for the right reasons 3. Migrate incrementally 4. Begin with the end in mind 5. Migrate high-value modules first 6. Success is improved velocity and reliability
- 4. @crichardson Tomcat/App. Server The Monolithic architecture is not an anti-pattern Browser/ Client WAR/EAR MySQL Database Delivery management Order Management Kitchen Management Web UI Restaurant Management HTML REST/JSON Single deployable/ executable Modules
- 5. @crichardson Make the most of the monolithic architecture If software delivery is slow Optimize development process Improve deployment pipeline = more automation Improve team autonomy Modularize the monolith to enable independent development Eliminate hand-offs and create cross functional teams If technology stack is obsolete modernize to a new monolith …
- 6. @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
- 7. @crichardson Agenda 1. Make the most of your monolith 2. Adopt microservices for the right reasons 3. Migrate incrementally 4. Begin with the end in mind 5. Migrate high-value modules first 6. Success is improved velocity and reliability
- 8. The microservice architecture is an architectural style that structures an application as a set of loosely coupled services Each microservice is: • highly maintainable and testable • independently deployable • organized around business capabilities • owned by a small team
- 9. @crichardson Process: Lean + DevOps/Continuous Delivery & Deployment Organization: Small, autonomous, product teams Architecture: microservices Testability Deployability Modularity Modularity Evolvability Maintainability Deliver software rapidly, frequently reliably and sustainably
- 10. @crichardson The microservice architecture is NOT magic pixie dust Adopting microservices won’t address: Poor code quality Lack of automated testing Poor development process …. And might make things worse! https://chrisrichardson.net/post/antipatterns/2019/01/07/ microservices-are-a-magic-pixie-dust.html
- 11. @crichardson Agenda 1. Make the most of your monolith 2. Adopt microservices for the right reasons 3. Migrate incrementally 4. Begin with the end in mind 5. Migrate high-value modules first 6. Success is improved velocity and reliability
- 12. @crichardson Monolith to microservices = application modernization Monolith Service Do it incrementally! Service Service Service
- 13. @crichardson Strangler Application http://www.martinfowler.com/bliki/StranglerApplication.html Incrementally migrate functionality from existing application to new (strangler) application
- 14. @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
- 15. @crichardsonDatabase Module Iteratively: Module => Service Monolith Service API Gateway Request Module Request Monolith Database Module Database Module Integration glue API API
- 16. @crichardson Iteratively: New feature = Service Monolith Service API Gateway Request DatabaseDatabase Integration glue
- 17. @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
- 18. @crichardson Agenda 1. Make the most of your monolith 2. Adopt microservices for the right reasons 3. Migrate incrementally 4. Begin with the end in mind 5. Migrate high-value modules first 6. Success is improved velocity and reliability
- 19. @crichardson Defining the correct service boundaries is critical (Using the latest, hot technology is not) https://chrisrichardson.net/post/antipatterns/2019/04/30/ antipattern-focus-on-technology.html
- 20. @crichardson Define your ideal target architecture upfront Begin with a short architecture definition effort It’s not set in stone Be prepared to learn and evolve Understanding your domain is key Event storming can help
- 21. Define coarse-grained services Service-per-team is a good starting point Only have more services if it solves a problem Accelerates testing Satisfies a non- functional requirement … https://microservices.io/patterns/decomposition/service-per-team.html
- 22. @crichardson Avoid runtime coupling => reduced availability Order Service Customer Service PUT /customer/id/credit availability(createOrder) = availability(OrderService) x availability(CustomerService) POST /order 😢 Order Customer creditLimit availableCredit
- 23. Try to make services self-contained Service can respond without waiting for response https://microservices.io/patterns/decomposition/self- contained-service.html Use asynchronous communication Events Asynchronous request/response e.g. https://microservices.io/patterns/data/saga.html messaging system Message Channel Payload Header
- 24. Avoid design-time coupling: design iceberg services Design-time coupling = services changing in lockstep Requires coordination between teams Reduces productivity Implementation DB API Small, stable API Large, complex implementation Private DB No shared business logic libraries
- 25. @crichardson Don’t be segment.com: shared library, design-time coupling 😀 https://segment.com/blog/goodbye-microservices/
- 26. @crichardson Agenda 1. Make the most of your monolith 2. Adopt microservices for the right reasons 3. Migrate incrementally 4. Begin with the end in mind 5. Migrate high-value modules first 6. Success is improved velocity and reliability
- 27. @crichardson 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 of decoupling: ∝ # inbound dependencies FTGO <<module>> Module A <<module>> Module B <<module>> Module C Ext. API Ext. API Ext. API Easy Difficult 0 1 2 Dependencies can determine ordering
- 30. @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
- 31. @crichardson Agenda 1. Make the most of your monolith 2. Adopt microservices for the right reasons 3. Migrate incrementally 4. Begin with the end in mind 5. Migrate high-value modules first 6. Success is improved velocity and reliability
- 32. @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 https://chrisrichardson.net/post/antipatterns/2019/01/14/antipattern-microservices-are-the-goal.html
- 33. @crichardson Summary: the six principles 1. Make the most of your monolith 2. Adopt microservices for the right reasons 3. Migrate incrementally 4. Begin with the end in mind 5. Migrate high-value modules first 6. Success is improved velocity and reliability