The microservice architecture: what, why, when and how?

@crichardson
The microservice architecture:
what, why, when and how?
Chris Richardson
Founder of Eventuate.io
Founder of the original CloudFoundry.com
Author of POJOs in Action and Microservices Patterns
@crichardson
chris@chrisrichardson.net
adopt.microservices.io
Copyright © 2023. Chris Richardson Consulting, Inc. All rights reserved

@crichardson
About Chris
http://adopt.microservices.io
Late 80s 2006 2008 2009
2012-

@crichardson
About Chris
https://chrisrichardson.net/

@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

@crichardson
O
V
I
D
-
1
9
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/
Thriving in today’s world
Businesses must be nimble, agile and innovate faster
Volatile
Uncertain
Complex
Ambiguous

@crichardson
Software is eating the world
Business critical
application
You must deliver software rapidly,
frequently, reliably and sustainably
You
Responsible for
S/W
VUCA

@crichardson
Goal Your reality
Measured by DORA metrics
+ your monolith’s technology stack
is out of date
https://cloud.google.com/devops/state-of-devops

@crichardson
O
V
I
D
-
1
9
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/
The success triangle
Process: DevOps/Continuous Delivery & Deployment
Organization:
Network of small,
loosely coupled, product teams
IT must deliver software
rapidly, frequently, reliably and sustainably.
Measured by the DORA metrics
Businesses must be
nimble, agile and
innovate faster
S/W
VUCA
Architecture:
???
Supports
Supports

@crichardson
Monolith or Microservice
architecture?
In reality: #itDepends
BUT
On what?
ask Twitter!

@crichardson
Suck/Rock Dichotomy
http://nealford.com/memeagora/2009/08/05/suck-rock-dichotomy.html

@crichardson
Patterns: a better way to
reason about architecture
Reusable solution
to a problem
occurring
in a context
and its consequences

@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

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

@crichardson
Data patterns
Communication patterns
Application
architecture
Cross-cutting concerns Security
Deployment
Maintaining data
consistency
External API
Reliability
Discovery
Transactional
messaging
Testing
Observability
UI
Decomposition
Database architecture
Querying
Communication style
Copyright
©
2023. Chris Richardson Consulting, Inc. All rights reserved. Learn-Build-Assess Microservices http://adopt.microservices.io
API gateway
Client-side discovery
Server-side
discovery
Service registry
Self registration
3rd party registration
Multiple Services
per host
Single Service per
Host
Service-per-
Container
Service-per-VM
Messaging
Remote Procedure
Invocation
Database per
Service
Saga
Shared
database
Microservice
Chassis
Backends for
frontends
Event
sourcing
Monolithic
architecture
Microservice
architecture
Motivating
Pattern
Solution
Pattern
Solution A Solution B
General Specific
Serverless
deployment
Circuit Breaker
Access Token
Domain-specific
Externalized
configuration
Consumer-driven
contract test
Service
Component Test
Exception
tracking
Distributed
tracing
Audit logging
Application
metrics
Log
aggregation
Health check
API
Service
deployment
platform
Server-side page
fragment
composition
Client-side UI
composition
Decompose by
business capability
Decompose by
subdomain
CQRS
Transaction
log tailing
Transactional
Outbox
Polling
publisher
API
Composition
Consumer-side
contract test
Sidecar
Service mesh
Aggregate
Domain event
Log deployments and changes
Self-contained
Service
Service per team
Service
Template
The Microservice Architecture Pattern Language
Application
patterns
Infrastructure patterns
Application Infrastructure patterns

@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

@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

@crichardson
Microservice
architecture
Monolithic
architecture
Bene
fi
ts
Drawbacks
Issues
Context
Solution
Forces
Bene
fi
ts
Drawbacks
Issues
Solution

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…

@crichardson
Microservice
architecture
Monolithic
architecture
Bene
fi
ts
Drawbacks
Issues
Context
Solution
Forces
Bene
fi
ts
Drawbacks
Issues
Solution
Subdomain A
«Aggregate»
X
Subdomain B
«Aggregate»
Y
Service A Service B
Attraction
Simple interactions
Eﬃcient 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

@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
Repulsive dark energy forces
Characteristics:
• Resource requirements
• Regulations, e.g. SaMD/PCI
• Business criticality/tier
• Security, e.g. PII, …
• DDD core/supporting/generic
• ...

@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
Eﬃcient interactions
Prefer ACID over BASE
Minimize runtime coupling
Minimize design time coupling
Attractive dark matter forces
SystemOperation()
Generates

@crichardson
Pattern: monolithic
architecture
*Or multiple tightly coupled (via database) services
The monolithic architecture
is an architectural style
that structures the application
as a single* executable
component

@crichardson
Github Repository
«Gradle Project»
FtgoApplication
«Gradle Subproject»
main
main
orders
orders.web
customerAPI
orders.
domain
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

@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

Pattern: microservice
architecture
Loosely coupled
Independently
deployable
Implements a
business capability
Owned 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:

@crichardson
API
What’s a service…?
Operations
Event
Publisher
Commands
Queries
Synchronous
REST/gRPC
Asynchronous
Messaging
Events
Event
Subscriber
API
Client
Invokes
Operations
Events
Service
Database
Responsibilities
Service
Name

@crichardson
Runtime
environment
Infrastructure
Git repository
Application
code
Infrastructure
code
… what’s a service?
Application
code
Infrastructure
code
Deployment
pipeline
Deployable
/executable
Service
instance
Service
instance
Infrastructure

@crichardson
Services are independently
deployable
https://microservices.io/post/architecture/2022/05/04/microservice-architecture-essentials-deployability.html
End-to-end tests
Test collaboration with contract tests

@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

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

Design iceberg services
Implementation
DB
API
Small, stable
API
Large, complex
implementation Change
Visible
Invisible
https://microservices.io/microservices/2020/02/04/jfokus-geometry-of-microservices.html

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

@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

@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

@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

@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

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

@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

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

@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

@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
Repulsive dark energy forces
Characteristics:
• Resource requirements
• Regulations, e.g. SaMD/PCI
• Business criticality/tier
• Security, e.g. PII, …
• DDD core/supporting/generic
• ...

@crichardson
Principle #3: Begin with the end in
mind - de
fi
ne a target architecture
Target architecture
Assemblage process
http://microservices-assemblage.io/

@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

@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

@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

@crichardson
Deciding to use the microservice
architecture is just the beginning
Deployment
De
fi
ne services
Observe
UI
Communication
Test
Cross cutting concerns
“Data”

@crichardson
Data patterns
Application
architecture
Cross-cutting concerns Security
Deployment
Maintaining data
consistency
External API
Reliability
Discovery
Transactional
messaging
Testing
Observability
UI
Decomposition
Querying
Communication style
Copyright
©
2023. Chris Richardson Consulting, Inc. All rights reserved. Learn-Build-Assess Microservices http://adopt.microservices.io
API gateway
Client-side discovery
Server-side
discovery
Service registry
Self registration
3rd party registration
Multiple Services
per host
Single Service per
Host
Service-per-
Container
Service-per-VM
Messaging
Remote Procedure
Invocation
Database per
Service
Saga
Shared
database
Microservice
Chassis
Backends for
frontends
Event
sourcing
Monolithic
architecture
Microservice
architecture
Motivating
Pattern
Solution
Pattern
Solution A Solution B
General Specific
Serverless
deployment
Circuit Breaker
Access Token
Domain-specific
Externalized
configuration
Consumer-driven
contract test
Service
Component Test
Exception
tracking
Distributed
tracing
Audit logging
Application
metrics
Log
aggregation
Health check
API
Service
deployment
platform
Server-side page
fragment
composition
Client-side UI
composition
Decompose by
business capability
Decompose by
subdomain
CQRS
Transaction
log tailing
Transactional
Outbox
Polling
publisher
API
Composition
Consumer-side
contract test
Sidecar
Service mesh
Aggregate
Domain event
Log deployments and changes
Self-contained
Service
Service per team
Service
Template
The Microservice Architecture Pattern Language
Application
patterns
Infrastructure patterns
Application Infrastructure patterns
Application
Infrastructure
Application and
Infrastructure

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)

@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

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

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

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

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

The microservice architecture: what, why, when and how?

Recommended

More Related Content

What's hot (20)

Similar to The microservice architecture: what, why, when and how? (20)

More from Chris Richardson (20)

Recently uploaded (20)

The microservice architecture: what, why, when and how?