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 chris@chrisrichardson.net http://adopt.microservices.io Copyright © 2020. Chris Richardson Consulting, Inc. All rights reserved

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

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 ﬁrst 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 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

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

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

19. @crichardson Deﬁning 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 Deﬁne your ideal target architecture upfront Begin with a short architecture deﬁnition effort It’s not set in stone Be prepared to learn and evolve Understanding your domain is key Event storming can help

21. Deﬁne coarse-grained services Service-per-team is a good starting point Only have more services if it solves a problem Accelerates testing Satisﬁes 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/

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 Difﬁcult 0 1 2 Dependencies can determine ordering

30. @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 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 ﬁrst 6. Success is improved velocity and reliability

34. @crichardson @crichardson chris@chrisrichardson.net http://adopt.microservices.io Questions? 35% discount with code ctwcto20