This is a presentation that gave at the O'Reilly Software Architecture Superstream: Software Architecture Patterns.
The talk's focus is the microservices pattern language.
However, it also shows how thinking with the pattern mindset - context/problem/forces/solution/consequences - leads to better technically decisions.
The microservices architecture offers tremendous benefits, but it’s not a silver bullet. It also has some significant drawbacks. The microservices pattern language—a collection of patterns that solve architecture, design, development, and operational problems—enables software developers to apply the microservices architecture effectively. I provide an overview of the microservices architecture and examines the motivations for the pattern language, then takes you through the key patterns in the pattern language.
5. @crichardson
Agenda
Why a pattern language for microservices?
Core patterns: Monolith vs. Microservices
Distributed data patterns in a microservice architecture
6. @crichardson
“The software architecture of a computing system is the set of structures needed
to reason about the system, which comprise software elements, relations among
them, and properties of both.”
Documenting Software Architectures, Bass et al
Development
• Maintainability
• Testability
• Deployability
• …
Architect
Nonfunctional requirements
Runtime
• Scalability
• Performance
• Availability
• …
Satisfies
Defines
Architecture
8. @crichardson
Patterns: a better way to
reason about architecture
Reusable solution
to a problem
occurring
in a context
and its consequences
9. @crichardson
Alternative
Pattern
The structure of a pattern
Pattern
Benefits
Drawbacks
Issues
Alternative
Pattern
Patterns
that
address
issues
Context
Problem
Solution
aka the situation
(conflicting) issues/
requirements/etc to
address
Force
Consequences
10. Pattern language
A collection of
related patterns
that identify and
solve problems in
a particular domain
http://en.wikipedia.org/wiki/A_Pattern_Language
Motivating
Pattern
Solution
Pattern
Solution
Pattern A
Solution
Pattern B
Generic
Pattern
Specific
Pattern
Has
issue
Solves
issue
Alternative
solutions
Refines
Valuable
12. @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
15. Required architectural quality
attributes (a.k.a. -ilities)
“Complete their work without
communicating and coordinating with
people outside their team”
“Make large-scale changes to the design
of their system without depending on
other teams to make changes in their
systems or creating significant work for
other teams”
“We can do most of our testing without
requiring an integrated environment.”
“We can and do deploy or release our
application independently of other
applications/services it depends on.”
Loosely coupled
(Conway’s law)
Modular
Testable
Deployable
API encapsulates design decisions
18. Architecture is multi-
dimensional: 4+1 view model
Logical
View
Process
View
Deployment
View
Implementation
View
Scenarios
https://en.wikipedia.org/wiki/4%2B1_architectural_view_model
View = (elements, relations)
Scenario: shows how a view’s elements collaborate
19. 4+1 Logical view: “programming”
Logical
View
Process
View
Deployment
View
Implementation
View
Scenarios
Elements: classes, packages, subdomains
Relations: inheritance, associations, …
About Subdomains
• Business capability/function/etc
• Team-sized
«Subdomain»
Customer
management
firstName
lastName
«aggregate»
Customer
«Subdomain»
Order
management
deliveryTime
…
«aggregate»
Order
Quantity
…
«aggregate»
OrderLineItem
«Subdomain»
Restaurant
management
name
…
«aggregate»
Restaurant
name
…
«aggregate»
MenuItem
Customer management team
Owns
Order management team
Owns
Restaurant management team
Owns
21. @crichardson
Choice of architectural styles
Application
Service
≪subdomain≫
≪subdomain≫
≪subdomain≫
≪subdomain≫
Service
Service
Application
≪subdomain≫
≪subdomain≫
≪subdomain≫
≪subdomain≫
Monolithic architecture:
One component
Microservice architecture:
Many components
Problem: how to partition subdomains into components?
23. @crichardson
Grouping subdomains into
components: together or separate?
≪subdomain≫
Customer
≪aggregate≫
Customer
≪subdomain≫
Order
≪aggregate≫
Order
Attraction
Repulsion
Generated by
system operations
Simple components
Team-sized services
Fast deployment pipeline
…
Dark energy: an anti-
gravity that’s accelerating
the expansion of the
universe
Dark matter: an invisible
matter that has a
gravitational effect on stars
and galaxies.
https://www.nasa.gov/feature/goddard/2020/new-hubble-data-explains-missing-dark-matter
Simple interactions
Prefer ACID or BASE
Minimize runtime coupling
…
https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html
24. @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
Cost effective scaling
Segregate regulated software
Segregate highly available components
25. @crichardson
Dark matter: attractive forces
subdomains in same service
https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html
System Operation()
Service
Service
«Subdomain» A
«Aggregate»
X
«Subdomain» B
«Aggregate»
Y
Simple interactions
Prefer ACID over BASE
Minimize runtime coupling
Efficient inter-service communication
Minimize design time coupling
26. @crichardson
The role of the architect is to
balance conflicting forces
Minimize attraction
Service
Subdomain
Subdomain
Minimize
repulsion
Service
Subdomain
Subdomain
Minimize
repulsion
Conflicting goals
30. @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
31. @crichardson
Monolithic architecture: benefits and drawbacks
Repulsive forces
Simple components ✅ or ❌ ∝1/ size
Team autonomy ✅ or ❌ ∝1/ size
Fast deployment pipeline ✅ or ❌ ∝1/ size
Support multiple technology stacks ❌
Cost effective scaling ✅ if role-based deployments
Segregate regulated software ❌
Segregate highly available components ❌
Attractive forces
Simple interactions ✅
Prefer ACID over BASE ✅
Minimize runtime coupling ✅
Efficient inter-service communication ✅
Minimize design time coupling ✅
Depends on
size
It can’t resolve these forces
32. @crichardson
Issues
How to enable many developers to
frequently commit their changes?
How to improve productivity by enabling
developers to work on part of the
application?
How to enable teams to work
independently?
How to accelerate deployment pipeline?
Merge Queue
Modular
Monolith
Parallelization
Simple components ✅ or ❌ ∝1/ size
Team autonomy ✅ or ❌ ∝1/ size
Fast deployment
pipeline
✅ or ❌ ∝1/ size
33. Solution: microservice
architecture
Highly maintainable and
testable
Minimal lead time (time from
commit to deploy)
Loosely coupled
Independently deployable
Implements a business
capability
Owned/developed/tested/
deployed by a small team
An architectural
style
that structures an
application as a
set of deployable/
executable units,
a.k.a. services
A service is:
34. @crichardson
Microservice architecture:
Many components
Production
Github Repository
Github Repository
«Gradle project»
orders
orders.web
orders.
domain
«Gradle project»
customers
customers.
persistence
orders.
persistence
Customer team
Order team
Deployment
pipeline
«Executable JAR»
Order
Service
customers.
domain
customers.
web
customers.
main
orders.main
«Executable JAR»
Customer
Service
Deployment
pipeline
«Service Instance»
Order
Service
«Service Instance»
Customer
Service
Inter-service
Communication
35. @crichardson
Microservice architecture: benefits and drawbacks
Repulsive forces
Simple components ✅
Team autonomy ✅
Fast deployment pipeline ✅
Support multiple technology stacks ✅
Cost effective scaling ✅
Segregate regulated software ✅
Segregate highly available components ✅
Attractive forces
Simple interactions ❌
Prefer ACID over BASE ❌
Minimize runtime coupling ❌
Efficient inter-service communication ❌
Minimize design time coupling ❌
Key issue
Must group
subdomains to:
• Maximize benefits
• Minimize drawbacks
Potential benefits
Potential drawbacks
36. @crichardson
Many other issues: how to …?
Deployment
Define services
Observe
UI
Communication
Test
Cross cutting concerns
“Data”
37. @crichardson
Agenda
Why a pattern language for microservices?
Core patterns: Monolith vs. Microservices
Distributed data patterns in a microservice architecture
38. @crichardson
Context: you’ve applied the
microservice architecture
Application
Customer
Service
≪entity≫
Customer
Order Service
≪entity≫
Order
createCustomer()
createOrder()
findOrder()
findOrderHistory()
System operations
Transactional
• Persistent
• Owned by service
Read/
Write
40. @crichardson
Pattern: Shared database schema
Order Service
Customer
Service
Order
table
Customer
table
createOrder()
ACID
Transaction
https://microservices.io/patterns/data/shared-database.html
41. @crichardson
Benefits and drawbacks: shared schema
Shared
schema
Dark energy repulsive forces
Simple components ✅
Team autonomy ❌
Support multiple technology stacks ❌
Cost effective scaling ❌
Segregate highly available components ❌
Dark matter attractive forces
Simple interactions ✅
Prefer ACID over BASE ✅
Minimize runtime coupling ❌
Efficient inter-service communication ✅
Minimize design time coupling ❌
Simple ACID
BUT
tightly
coupled, …
42. @crichardson
Pattern: Private database schema
Orders Service
Customer
Service
Order
table
Customer
table
API
createOrder()
Transaction
???
https://microservices.io/patterns/data/database-per-service.html
43. @crichardson
Context: Applied private database schema
Problem: How to implement transactions?
https://en.wikipedia.org/wiki/Two-phase_commit_protocol
Pattern: 2PC Pattern: Saga
https://microservices.io/patterns/data/saga.html
44. @crichardson
Benefits and drawbacks
Private schema
2PC Saga
Dark energy repulsive forces
Simple components ✅ ?
Team autonomy ❌ ✅
Support multiple technology stacks ❌ ✅
Cost effective scaling ❌ ✅
Segregate highly available components ❌ ✅
Dark matter attractive forces
Simple interactions ✅ ?
Prefer ACID over BASE ✅ ❌
Minimize runtime coupling ❌ ✅
Efficient inter-service communication ? ?
Minimize design time coupling ✅ ✅
😀
😀
😀
😢
46. @crichardson
Summary: The Microservices pattern
language is a great way to …
Think about architecture
Discuss architecture
Choose an architecture: monolith or microservices