This is a talk I gave at DDD SoCal. 1. Make the most of your monolith 2. Adopt microservices for the right reasons 3. It’s not just architecture 4. Get the support of the business 5. Migrate incrementally 6. Know your starting point 7. Begin with the end in mind 8. Migrate high-value modules first 9. Success is improved velocity and reliability 10. If it hurts, don’t do it

1. @crichardson
Decompose your monolith: Six Ten
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
X

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

3. Agenda
1. Make the most of your
monolith
2. Adopt microservices for
the right reasons
3. It’s not just architecture
4. Get the support of the
business
5. Migrate incrementally
6. Know your starting point
7. Begin with the end in mind
8. Migrate high-value
modules first
9. Success is improved
velocity and reliability
10.If it hurts, don’t do it

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. Agenda
1. Make the most of your
monolith
2. Adopt microservices for
the right reasons
3. It’s not just architecture
4. Get the support of the
business
5. Migrate incrementally
6. Know your starting point
7. Begin with the end in mind
8. Migrate high-value
modules first
9. Success is improved
velocity and reliability
10.If it hurts, don’t do it

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. Agenda
1. Make the most of your
monolith
2. Adopt microservices for
the right reasons
3. It’s not just architecture
4. Get the support of the
business
5. Migrate incrementally
6. Know your starting point
7. Begin with the end in mind
8. Migrate high-value
modules first
9. Success is improved
velocity and reliability
10.If it hurts, don’t do it

12. @crichardson
Anti-pattern:
Walking in front
with a red flag
https://www.dedionboutonclub.co.uk/imperial_institute_page1.html
Anti-pattern:
Red flag law

13. @crichardson
Adopting microservices without
changing process, policies and
organization
Silo’d teams
Manual testing
Monthly deploys at midnight
…

14. @crichardson
Embrace the success triangle
Process: Lean + DevOps/Continuous Delivery & Deployment
Organization: Small,
autonomous,
product teams
Architecture:
microservices
Deliver software
rapidly, frequently
reliably and
sustainably

15. What is DevOps?
Set of practices where
developers, testers
(dev) and IT operations
(ops) collaborate and
communicate to deliver
software rapidly,
frequently, and reliably
http://itrevolution.com/devops-handbook

16. @crichardson
Modern software development: rapid and
reliable
Faster
More reliable

17. The research shows…
Software Delivery
Performance
Lead time, Deployment
frequency, Mean Time To
Restore, Change Fail %
Organizational
Performance
Profitability, Productivity,
Market share
$
Impacts

18. @crichardson
Enterprises must be nimble
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/
C
O
VID
-19https://chrisrichardson.net/post/training/2020/05/03/it-in-the-time-of-covid.html

19. High performance
organization: team of teams
5-9 people - promotes trust
Long-lived - enables trust and high
performance
Empowered/autonomous
Cross functional- eliminates time
consuming hand-offs
Owns suitably sized software
“component”
Promotes long-term sustainable
development
Prevents cognitive overload

20. @crichardson
Hierarchy vs. network
Information
Commands
https://www.forbes.com/sites/jacobmorgan/2015/07/06/the-5-types-of-organizational-structures-part-1-the-hierarchy/#75b712145252
Larger the company,
More layers, slower
decision making
Team
Team
Team
Team
Team
Team
Grow by adding
teams, faster/localized
decision making

21. @crichardson
Tightly coupled vs. loosely
coupled organizations
Loosely
coupled
Tightly
coupled

22. Agenda
1. Make the most of your
monolith
2. Adopt microservices for
the right reasons
3. It’s not just architecture
4. Get the support of the
business
5. Migrate incrementally
6. Know your starting point
7. Begin with the end in mind
8. Migrate high-value
modules first
9. Success is improved
velocity and reliability
10.If it hurts, don’t do it

23. @crichardson
Migrating a monolith to microservices
=
An investment that takes time away
from developing features
The support of the business is essential

24. @crichardson
Ideally:
The business “We can’t make money because
of X and we need engineering to fix it”
For example:
We can’t sell new versions because customers
find that releases have too many bugs that
cause downtime and lost revenue

25. @crichardson
Otherwise, you need to build a business
case:
Microservices
=

26. @crichardson
Example: If we convert module
X to a service then we can
Improve testability => fewer bugs
Lower support calls/costs
Improved customer satisfaction and retention
Accelerate development
Develop features faster => more competitive => more $$$
Run experiments more frequently
…

27. @crichardson
Hypothesis-driven
development
66% of your product ideas are at best useless
Teams should make product management decisions based on
feedback from real customers
Microservices DevOps More frequent, safer
deployments More frequent experiments

28. @crichardson
DevOps and Microservices at Intuit:
frequent and safe deployments
No code
freeze!

29. Agenda
1. Make the most of your
monolith
2. Adopt microservices for
the right reasons
3. It’s not just architecture
4. Get the support of the
business
5. Migrate incrementally
6. Know your starting point
7. Begin with the end in mind
8. Migrate high-value
modules first
9. Success is improved
velocity and reliability
10.If it hurts, don’t do it

30. @crichardson
Monolith to microservices =
application modernization
Monolith
Service
Do it incrementally!
Service
Service
Service

31. @crichardson
Strangler
Application
http://www.martinfowler.com/bliki/StranglerApplication.html
Incrementally migrate
functionality
from
existing application
to
new (strangler)
application

32. @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

33. @crichardsonDatabase
Module
Iteratively: Module => Service
Monolith Service
API Gateway
Request
Module
Request
Monolith
Database
Module
Database
Module
Integration
glue
API
API

34. @crichardson
Iteratively: New feature = Service
Monolith Service
API Gateway
Request
DatabaseDatabase
Integration
glue

35. @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

36. Agenda
1. Make the most of your
monolith
2. Adopt microservices for
the right reasons
3. It’s not just architecture
4. Get the support of the
business
5. Migrate incrementally
6. Know your starting point
7. Begin with the end in mind
8. Migrate high-value
modules first
9. Success is improved
velocity and reliability
10.If it hurts, don’t do it

37. @crichardson
Migrating a monolith to microservices
=
Converting one module at a time
=>
You need to know the modules!

38. @crichardson
Understanding your AS-IS
architecture is essential
BUT
Often knowledge is silo’d or absent

39. Visible architecture workshop:
create a shared understanding
Get the team(s) in a room, e..g 20+
architects from a global organization
Build a physical model of the AS-IS
architecture from Duplo, string, and
….
Creates the first shared
understanding of the AS-IS
architecture
https://www.scrumalliance.org/
learn-about-scrum/community-
webinars/webinar-replays/
collaboration-at-scale/managing-
technical-architectures
@lukehohmann

40. Agenda
1. Make the most of your
monolith
2. Adopt microservices for
the right reasons
3. It’s not just architecture
4. Get the support of the
business
5. Migrate incrementally
6. Know your starting point
7. Begin with the end in mind
8. Migrate high-value
modules first
9. Success is improved
velocity and reliability
10.If it hurts, don’t do it

41. @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

42. @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

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

44. @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

45. @crichardson
Self-contained service:
Can handle a synchronous
request without waiting for a
response from another service
https://microservices.io/patterns/decomposition/self-contained-service.html

46. @crichardson
Order
Service
Order Management
Customer Management
Improving availability: replace
service with module
POST /order
Order
Customer
creditLimit
availableCredit
availability(createOrder) =
availability(OrderService)
More available 😄
Larger service/
team 😢
Response =
validation
outcome 😄

47. @crichardson
Improving availability: CQRS
Order
Service Customer
Service
availability(createOrder) =
availability(OrderService)
POST /order
Customer
Created
More available 😄
Complex/Costly 😢
Response =
validation
outcome 😄
Customer
creditLimit
availableCredit
Replicated
Owned
Customer
creditLimit
availableCredit
Credit Limit
Changed
https://microservices.io/patterns/data/cqrs.html

48. @crichardson
Improving availability: sagas
Order
Service
Customer
Service
availability(createOrder) =
availability(OrderService)
POST /order
Credit
Reserved
More available 😄
Complexity of sagas 😢
Order created
Response =!
Validation outcome 😢
Order events
Customer events
Order creditLimit
availableCredit
https://microservices.io/patterns/data/saga.html

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

50. @crichardson
Don’t be segment.com: shared
library, design-time coupling 😀
https://segment.com/blog/goodbye-microservices/

51. Agenda
1. Make the most of your
monolith
2. Adopt microservices for
the right reasons
3. It’s not just architecture
4. Get the support of the
business
5. Migrate incrementally
6. Know your starting point
7. Begin with the end in mind
8. Migrate high-value
modules first
9. Success is improved
velocity and reliability
10.If it hurts, don’t do it

52. @crichardson
Start with the modules that
would give you the greatest
return on investment (ROI)

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

54. @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

55. @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

56. Agenda
1. Make the most of your
monolith
2. Adopt microservices for
the right reasons
3. It’s not just architecture
4. Get the support of the
business
5. Migrate incrementally
6. Know your starting point
7. Begin with the end in mind
8. Migrate high-value
modules first
9. Success is improved
velocity and reliability
10.If it hurts, don’t do it

57. @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

58. Agenda
1. Make the most of your
monolith
2. Adopt microservices for
the right reasons
3. It’s not just architecture
4. Get the support of the
business
5. Migrate incrementally
6. Know your starting point
7. Begin with the end in mind
8. Migrate high-value
modules first
9. Success is improved
velocity and reliability
10.If it hurts, don’t do it

59. @crichardson
The potential consequences
of decomposition
Complexity
Complex sagas
Too many services
Tight coupling:
Design time: services changing in lock step
Runtime: high latency, low availability

60. @crichardson
These problems are
consequences of your decisions
https://condenaststore.com/featured/doctor-says-to-patient-who-has-a-large-sword-peter-c-vey.html

61. @crichardson
Transform the architecture to
eliminate the problem
Transform your microservice architecture
Move responsibilities from one service to another
Replace service with a library
Merge services
…
Use the monolithic architecture

62. Summary: the ten principles
1. Make the most of your
monolith
2. Adopt microservices for
the right reasons
3. It’s not just architecture
4. Get the support of the
business
5. Migrate incrementally
6. Know your starting point
7. Begin with the end in mind
8. Migrate high-value
modules first
9. Success is improved
velocity and reliability
10.If it hurts, don’t do it

63. @crichardson
@crichardson chris@chrisrichardson.net
adopt.microservices.io
Questions?