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.

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

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