DDD SoCal: Decompose your monolith: Ten principles for refactoring a monolith to microservices

@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

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

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 ﬁrst
9. Success is improved
velocity and reliability
10.If it hurts, don’t do it

@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

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

@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

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

@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

@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

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

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

@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

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

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

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

@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

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

@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

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

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

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

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

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

@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

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

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

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

@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

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

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

@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

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

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

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

@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

@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

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

@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

@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

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

@crichardson
Improving availability: CQRS
Order
Service Customer
Service
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

@crichardson
Improving availability: sagas
Order
Service
Customer
Service
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

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

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

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

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

@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

@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

@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

@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

@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

@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

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 ﬁrst
9. Success is improved
velocity and reliability
10.If it hurts, don’t do it

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

DDD SoCal: Decompose your monolith: Ten principles for refactoring a monolith to microservices

Recommended

More Related Content

What's hot (20)

Similar to DDD SoCal: Decompose your monolith: Ten principles for refactoring a monolith to microservices (20)

More from Chris Richardson (17)

Recently uploaded (20)

DDD SoCal: Decompose your monolith: Ten principles for refactoring a monolith to microservices