4. @crichardson
Agenda
Developing software for today’s crazy world
Architecture patterns for modern software
Migrating a monolith to microservices
The microservices pattern language is your guide
6. @crichardson
Software is eating the world
Business critical
application
You must deliver software rapidly,
frequently, reliably and sustainably
You
Responsible for
S/W
VUCA
10. @crichardson
Agenda
Developing software for today’s crazy world
Architecture patterns for modern software
Migrating a monolith to microservices
The microservices pattern language is your guide
12. @crichardson
Patterns: a better way to
reason about architecture
Reusable solution
to a problem
occurring
in a context
and its consequences
13. @crichardson
Alternative
Pattern
The structure of a pattern
Pattern
Bene
fi
ts
Drawbacks
Issues
Alternative
Pattern
Patterns
that
address
issues
Context
Problem
Solution
aka the situation
(con
fl
icting) issues/
requirements/etc to
address
Forces
Consequences
predecessor
successor
14. Pattern language: collection of
related patterns in a domain
http://en.wikipedia.org/wiki/A_Pattern_Language
Access to Water
Promenade
Local townhall
Intimacy gradient
Light on two sides
Alternative
Pattern
Pattern Issues
Alternative
Pattern
Patterns
that
address
issues
predecessor
successor
16. @crichardson
Pattern
The pattern language guides you
when developing an architecture
Pattern
Pattern
Context
Problem
Forces
Consequences
Pattern
Solution
Issues
Select
Find
applicable
patterns
Repeat
Problem
Context
Updated
context
Sub-
Problem
Matches
Solves
Assess trade-offs
Pattern
Solution
17. @crichardson
Microservice
architecture
Monolithic
architecture
Bene
fi
ts
Drawbacks
Issues
Context
Problem: what is the application’s architecture?
Solution
Forces
Bene
fi
ts
Drawbacks
Issues
Solution
Application
≪service≫
Order Management
≪module≫
Order REST API
≪module≫
Order Domain
≪module≫
Order Persistence
≪ service ≫
Kitchen Management
≪module≫
Kitchen REST API
≪module≫
Kitchen Domain
≪module≫
Kitchen Persistence
≪service≫
…
Browser
Order
Database
User
API Gateway/BFF
Kitchen
Database
Message
broker
Application.JAR
≪module≫
Order Management
≪module≫
Order REST API
≪module≫
Order Domain
≪module≫
Order Persistence
≪module≫
Kitchen Management
≪module≫
Kitchen REST API
≪module≫
Kitchen Domain
≪module≫
Kitchen Persistence
≪module≫
…
Browser Database
User
Microservices
Monolith
20. Fraud
Service
Customer
Service
Monolith
Problem: how to group subdomains to form services?
<<Subdomain>>
Order
Management
<<Subdomain>>
Customer
Management
<<Subdomain>>
Fraud
Management
<<Subdomain>>
Fraud
Detection
Order team
Customer
team
Fraud Team
Slices of business functionality
a.k.a. business capabilities
owns
owns
owns
How to
group?
<<Subdomain>>
Order
Management
<<Subdomain>>
Customer
Management
<<Subdomain>>
Fraud
Management
<<Subdomain>>
Fraud
Detection
Order
Service
<<Subdomain>>
Order
Management
<<Subdomain>>
Customer
Management
<<Subdomain>>
Fraud
Management
<<Subdomain>>
Fraud
Detection
…OR…
22. @crichardson
Microservice
architecture
Monolithic
architecture
Bene
fi
ts
Drawbacks
Issues
Context
Problem: what is the application’s architecture?
Solution
Forces
Bene
fi
ts
Drawbacks
Issues
Solution
Subdomain A
«Aggregate»
X
Subdomain B
«Aggregate»
Y
Service A Service B
Attraction
Simple interactions
Efficient interactions
Prefer ACID over BASE
Minimize runtime coupling
Minimize design time coupling
Simple components
Team autonomy
Fast deployment pipeline
Support multiple technology stacks
Segregate by characteristics
Repulsion
Dark energy
Dark matter
Metaphor for
Metaphor for
https://microservices.io/post/microservices/2021/11/30/dark-matter-dark-energy.html
23. @crichardson
Dark energy repulsive forces
subdomains in different services
https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html
Service
Service
«Subdomain» A
«Aggregate»
X
«Subdomain» B
«Aggregate»
Y
Simple components
Team autonomy
Fast deployment pipeline
Support multiple technology stacks
Segregate by characteristics
Repulsive dark energy forces
Characteristics:
• Resource requirements
• Regulations, e.g. SaMD/PCI
• Business criticality/tier
• Security, e.g. PII, …
• DDD core/supporting/generic
• ...
24. @crichardson
Dark matter attractive forces
subdomains in same service
https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html
Subdomain A
«Aggregate»
X
Subdomain B
«Aggregate»
Y
Service A Service B
Simple interactions
Efficient interactions
Prefer ACID over BASE
Minimize runtime coupling
Minimize design time coupling
Attractive dark matter forces
SystemOperation()
Generates
27. @crichardson
Github Repository
«Gradle Project»
FtgoApplication
«Gradle Subproject»
main
main
«Gradle Subproject»
orders
orders.web
«Gradle Subproject»
customerAPI
orders.
domain
«Gradle Subproject»
customers
customers.
persistence
orders.
persistence
Customer team
Order team
Deployment pipeline
Production
FTGO
Application
Executable JAR
customers.
domain
customers.
web
customers.
api
Monolithic architecture (Modular):
single component
28. @crichardson
Monolithic architecture: bene
fi
ts and drawbacks
Repulsive forces
Simple components ✅ or ❌ ∝1/ size
Team autonomy ✅ or ❌ ∝1/ size
Fast deployment pipeline ✅ or ❌ ∝1/ size
Support multiple technology stacks ❌
Segregate by characteristic ❌
Attractive forces
Simple, ef
fi
cient interactions ✅
Prefer ACID over BASE ✅
Minimize runtime coupling ✅
Minimize design time coupling ✅
Modularization + build technology
enable the Monolithic Architecture to be
used for larger applications
BUT
the application can ultimately outgrow its
architecture when these forces cannot be
resolved
It can’t resolve these forces
33. @crichardson
Services are loosely
coupled: runtime coupling
Runtime coupling between
service A and B is the degree
to which the availability of
service A is affected by the
availability of service B
Order
Service
Customer
Service
POST /orders
1 PUT /customers/id
Response
4
2
3
Order
Service
Customer
Service
POST /orders
1
4
2
3
Order Created event
Credit Reserved Event
Tight: lower availability
Loose: higher availability
ID
partial Outcome
ID
Outcome
https://microservices.io/patterns/decomposition/self-contained-service.html
Saga
34. Loosely coupled: design-time
coupling
The degree to which service A is
forced to change in lock step with
service B
Caused by direct, indirect and implicit
dependencies
Lockstep changes:
Coordination between teams
Reduced productivity
Changes to Customer Service affect
Order Service
Rarely - Loose coupling
Often - Tight coupling
API
Order
Service
Customer
Service
reserveCredit()
createOrder()
Change
Change
Change
https://microservices.io/post/microservices/2021/05/21/qcon-2021-loose-design-time-coupling.html
36. Avoid shared database tables
Order
Service
Customer
Service
Database
Customer
table
Tight design-
time/runtime
coupling
Order
Service
Customer
Service
Order database
Order
table
Customer database
Customer
table
APIs
only
https://microservices.io/patterns/data/database-per-service.html
37. @crichardson
Services implements
business capabilities
Services are groups of subdomains
Services are NOT usually technical functions
e.g. Order Data Service Fraud
Service
Customer
Service
Order
Service
<<Subdomain>>
Order
Management
<<Subdomain>>
Customer
Management
<<Subdomain>>
Fraud
Management
<<Subdomain>>
Fraud
Detection
38. @crichardson
Dark
matter
A service is owned by a small
team…
Order team
Order
Service
<<Subdomain>>
Order
Management
Customer team
Customer
Service
<<Subdomain>>
Customer
Management
Order team
Order Service
<<Subdomain>>
Order
Management
Customer team
<<Subdomain>>
Customer
Management
Ensures team autonomy and
resolves other dark energy forces
Teams can still be mostly
autonomous
Dark
matter
https://microservices.io/patterns/decomposition/service-per-team.html
https://microservices.io/post/antipatterns/2019/05/21/antipattern-more-the-merrier.html
39. @crichardson
… Owned by a small team
Fraud Team
Fraud
Service
<<Subdomain>>
Fraud
Management
Fraud
Detection
Service
<<Subdomain>>
Fraud
Detection
Additional service solves
tangible problem, e.g.
resolves a dark energy
force
Java Python
40. @crichardson
Microservice architecture: Bene
fi
ts and drawbacks
Repulsive forces
Simple components ✅
Team autonomy ✅
Fast deployment pipeline ✅
Support multiple technology stacks ✅
Segregate by characteristics ✅
Attractive forces
Simple, ef
fi
cient interactions ❌
Prefer ACID over BASE ❌
Minimize runtime coupling ❌
Minimize design-time coupling ❌
Must design services
and collaborations to:
• Maximize bene
fi
ts
• Minimize drawbacks
Potential bene
fi
ts
Potential drawbacks
41. @crichardson
Use the microservice
architecture when:
Large application and/or development organization
Need multiple technology stacks
Segregating subdomains by their characteristics is bene
fi
cial
Resource requirements => better scalability
Business critically => better availability
Regulatory requirements => faster development
…
42. @crichardson
Agenda
Developing software for today’s crazy world
Architecture patterns for modern software
Migrating a monolith to microservices
The microservices pattern language is your guide
43. @crichardson
Six principles for migrating a
monolith to Microservices
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
fi
rst
6. Success is improved velocity and reliability
https://microservices.io/post/refactoring/2020/07/28/six-principles-for-refactoring-to-microservices.html
44. @crichardson
Principle #1: 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
…
45. @crichardson
If and only if that is
insuf
fi
cient* then consider
migrating to microservices
*Large, complex applications developed by a
(usually) large team that need to be delivered
rapidly, frequently, and reliably
46. @crichardson
Principle #2: Adopt microservices
for the right reasons
https://microservices.io/post/microservices/2021/11/30/dark-matter-dark-energy.html
Service
Service
«Subdomain» A
«Aggregate»
X
«Subdomain» B
«Aggregate»
Y
Simple components
Team autonomy
Fast deployment pipeline
Support multiple technology stacks
Segregate by characteristics
Repulsive dark energy forces
Characteristics:
• Resource requirements
• Regulations, e.g. SaMD/PCI
• Business criticality/tier
• Security, e.g. PII, …
• DDD core/supporting/generic
• ...
47. @crichardson
Principle #3: Begin with the end in
mind - de
fi
ne a target architecture
Target architecture
Assemblage process
http://microservices-assemblage.io/
48. @crichardson
Principle #4: Migrate incrementally
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
https://microservices.io/patterns/refactoring/strangler-application.html
49. @crichardson
Principle #5: Migrate high-
value modules
fi
rst
Bene
fi
t of extraction
Ease of extraction
High
High
Low
Low
Module B
Module A
Module C
Module D
Module E
50. @crichardson
Principle #6: Measuring
success
Success != Number of Microservices
Success = Improved DORA metrics:
Reduced lead time
Increased deployment frequency
Reduced changed failure rate
Improvements in other -ilities
…
Anti-pattern:
Microservices as the goal
https://microservices.io/post/antipatterns/2019/01/14/antipattern-microservices-are-the-goal.html
51. @crichardson
Agenda
Developing software for today’s crazy world
Architecture patterns for modern software
Migrating a monolith to microservices
The microservices pattern language is your guide
52. @crichardson
Deciding to use the microservice
architecture is just the beginning
Deployment
De
fi
ne services
Observe
UI
Communication
Test
Cross cutting concerns
“Data”
54. Database architecture
Shared database
“Simple”, e.g. ACID
But creates tight design-time coupling
Best avoided
Database per service
Reduces design-time coupling
But potentially more complex, e.g. no
ACID transactions between services
https://microservices.io/patterns/data/shared-database.html
https://microservices.io/patterns/data/database-per-service.html
Service
Shared database
Service
Database
(Schema)
Service
Database per service
Service
Database
(Schema)
Database
(Schema)
55. @crichardson
Database per service => eventually
consistent service collaboration patterns
API Composition
Provider
Service
Service
query()
Composer
Provider
Service
Provider
Service
CQRS
Provider
Service
Service
query()
View
Provider
Service
Provider
Service
Event
Event
Event
Service
Service Service
Transaction
Compensating
transaction
Transaction
Compensating
transaction
Transaction
Compensating
transaction
command()
Saga
Service
Service
command()
Replica Source
Event
Command-side replica
Commands
Queries
https://microservices.io/patterns/index.html#data-management
56. Communication patterns
Remote procedure invocation
e.g. REST
Simple and familiar
But results in tight runtime coupling
Use carefully
Asynchronous messaging
e.g. events
Loose runtime coupling
More complex
Preferred
https://microservices.io/patterns/index.html#style
Service Service
Request
Response
Remote Procedure Invocation
Service Service
Messaging
Message
channel
57. Deployment patterns
Numerous options with
different trade-offs
Use serverless if you can
Otherwise, use containers
Virtual Machine
Service
Service per VM
Container
Service
Service per Container
Serverless infrastructure
Service
Serverless
Serverless framework
58. Summary
Monolith or microservices? #itDepends
The microservices pattern language is your guide
Dark energy and dark matter forces drive the design
Remember the principles for refactoring to microservices
Incrementally refactor a monolith to microservices
adopt.microservices.io @crichardson