YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy, Dark Matter Perspective

Chris Richardson
Chris RichardsonFounder of Eventuate, Inc - a microservices startup
@crichardson
Migrating a monolith to
microservices? A dark energy,
dark matter perspective
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 © 2022. Chris Richardson Consulting, Inc. All rights reserved
@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
@crichardson
Adopting the microservice
architecture will make
everything wonderful,
right?
Hint: it won’t
@crichardson
Presentation goal
Using the
dark energy and dark matter forces
to decide whether to refactor a
monolith to microservices
@crichardson
About Chris
http://adopt.microservices.io
Late 80s 2006 2008 2009
2012-
@crichardson
Agenda
Architecting for modern software delivery
Dark energy and dark matter: forces that drive the architecture
Dark energy: encouraging decomposition
Dark matter: resisting decomposition
@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
Required architectural quality
attributes (.a.k.a. -ilities)
DevOps
Autonomous Teams
Long-lived applications
Testability
Deployability
Loose coupling
Evolvability
Enable incremental upgrades of technology stack
@crichardson
Make the most of the monolith
Process: adopt DevOps and automate
Organization:
Restructure and increase
autonomy
Monolithic architecture:
Modularize and modernize
Success triangle
@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
On the other hand:
Improving the monolith can
take a while
THEREFORE
Implement urgent new
features as services now
@crichardson
Strangler Fig Pattern: Incrementally
refactoring a monolith to services
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
Stop/resume
at any point
When should you migrate?
And, which parts?
@crichardson
Agenda
Architecting for modern software delivery
Dark energy and dark matter: forces that drive the architecture
Dark energy: encouraging decomposition
Dark matter: resisting decomposition
@crichardson
How to de
fi
ne an
Architecture…
Application
≪subdomain≫
Customer
management
≪aggregate≫
Customer
≪subdomain≫
Order
management
≪aggregate≫
Order
createCustomer()
createOrder()
fi
ndOrder()
fi
ndOrderHistory()
System operations
Distill
Requirements The “requests” that the
application implements
Have SLOs
Customer Team
Order Team
About Subdomains
• Business capability/function/etc
• Logical view: packages and classes
• Team-sized
• Loosely coupled (Conways law)
1
2
Functional requirements
As a consumer
I want to place an Order
So that I can ….
As a Restaurant
I want to accept an Order
So that I can ….
Event storming
Wireframe/UI mockups
Available
Restaurants
Restaurant
Menu
System quality attributes
• SLA: Reliability/Latency
• Scalability
• …
@crichardson
Kitchen Service
Delivery Service
Order Service
createOrder()
… how to de
fi
ne an Architecture
createOrder()
<<subdomain>>
Order Management
Order
System operations
<<subdomain>>
Order
Management
<<subdomain>>
Kitchen
Management
<<subdomain>>
Delivery
Management
<<subdomain>>
Courier
Management
Group
subdomains
into services
Application
Collaboration
Design
collaborations
for distributed
operations
createOrder()
3
Monolith or
Microservices
@crichardson
Grouping subdomains into
components: together or separate?
≪subdomain≫
Customer
≪aggregate≫
Customer
≪subdomain≫
Order
≪aggregate≫
Order
Attraction
Repulsion
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, ef
fi
cient interactions
Prefer ACID over BASE
Minimize runtime coupling
…
https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html
Generate
systemOperation()
@crichardson
Together or separate = Module vs. Service?
FTGO Monolith
Delivery
Service
FTGO Monolith
Delivery
Management
createOrder()
VS
createOrder()
Collaboration
Order
Management
…
Management
Order
Management
…
Management
Dark
Energy
Dark
Matter
Bene
fi
ts
Cost & Feasibility
@crichardson
Agenda
Architecting for modern software delivery
Dark energy and dark matter: forces that drive the architecture
Dark energy: encouraging decomposition
Dark matter: resisting decomposition
@crichardson
Repulsive forces subdomains
in different services
https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html
= reasons to migrate a module into a service
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
@crichardson
Simpler components/services
Service
Service
Service
Subdomain
A
Subdomain
A
Subdomain
B
Subdomain
B
More complex service
Simpler services: easier to
understand, develop, test, …
versus
Simplifying a monolith
Modularizing the monolith
helps reduce complexity
Developer can focus on their
module
BUT
Complexity ∝Size
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
customers.
domain
customers.
web
customers.
api
Module/New Feature → Service = simpler development
IF
• Module is actively being developed
• Monolith is large
@crichardson
Team autonomy = service per team
Service
Service
Service
Subdomain
A
Subdomain
A
Subdomain
B
Subdomain
B
Coordination required
Build, test and deploy
independently
vs.
Team A Team B Team A Team B
Monoliths and team autonomy
Modularization helps
BUT
Single code base
Autonomy ∝ 1/ # developers
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
Deployment
pipeline
Production
FTGO
Application
Executable JAR
customers.
domain
customers.
web
customers.
api
Module/New Feature → Service = increased autonomy
IF
• Module is actively being developed
• Many teams
@crichardson
Fast deployment pipeline
@mipsytipsy
https://speakerdeck.com/charity/cd?slide=17
Service
Subdomain
Subdomain
Service
Subdomain
Shorter
lead time
Simpler
build
Longer lead
time
More complex
build*
* Parallelizing building/testing partially helps
Service
Subdomain
vs.
@crichardson
Optimizing a monolith’s deployment pipeline
$ git pull
$./gradlew test
$ git push
! [rejected] ….
Use merge queue
Accelerate build/test:
• Incremental testing through DIP and ISP
• Parallelization/clustered builds
• Selective test execution
BUT if the application/team keeps growing
Then eventually the deployment pipeline = bottleneck
Module/New Feature → Service = faster deployment pipeline
IF
• Module is actively being developed
• Monolith is large
• Many teams
@crichardson
Support multiple technology
stacks
Service
Python
Service
Java
Service
JVM
Subdomain
A
Subdomain
A
Subdomain
B
Subdomain
B
Single technology stack
Upgrade together
Separate technology stacks
Right tool for the job
Upgrade independently
Experiment easily
versus
@crichardson
Monolith = single technology
stack
Single class path unless using exotic technology, eg. Layrry
Single version of each dependency => big bang upgrades
No opportunity to experiment
No possibility of using non-JVM technologies, e.g. Python
Module/New Feature → Service = multiple technology stacks
@crichardson
Separate subdomains by
characteristics
Subdomain characteristic Issue
Resource requirements Cost-effective, scalability
Regulations, e.g. SaMD/
PCI
DevOps vs. Slower regulated process
Business criticality/tier Maximize availability
Security, e.g. PII, … Improve security
DDD core/supporting/
generic
Focus on being competitive
@crichardson
Cost effective scaling
Service
Service
Service
Subdomain
A
Subdomain
A
Subdomain
B
Subdomain
B
versus
CPU MEM GPU
Scale together
• Wasteful
• Costly
CPU MEM GPU
Scale separately
• Ef
fi
cient
• Cheaper
Load Load Load Load
EC2: p4d.24xlarge EC2: p4d.24xlarge
EC2: m5.24xlarge
8x cost!
@crichardson
Example: Segregate by business criticality
Service
Service
Service
Payment
Processing
Payment
Processing
Merchant
management
Merchant
management
Shared infrastructure
Shared code base
Risk of interference
Separate infrastructure
Separate code base
Isolated
vs.
chargeCard()
2.9% + 30c/
request Revenue loss and penalties
chargeCard()
Critical
Important
@crichardson
Multiple “deployments” can address
some requirements
FTGO
Monolith
FTGO
Monolith
Router
chargeCard()
….()
SPRING_PROFILES_ACTIVE=….
SPRING_PROFILES_ACTIVE=….
Request
BUT not others:
• single code base
• ….
• Scalability
• Availability
• …
Module/New Feature → Service
=
Improves architecture via separation
@crichardson
Some parts of your monolith will
bene
fi
t more from microservices
e.g. actively being developed
=>
Using dark energy to identify
candidate services
@crichardson
Data science team
(Not “hardcore” devs)
ML-based
Fraud detection
Service
E-Commerce
Monolith
Develops
Faster deployment
pipeline
Python
technology stack
Simpli
fi
ed development
experience
Improved autonomy
@crichardson
Agenda
Architecting for modern software delivery
Dark energy and dark matter: forces that drive the architecture
Dark energy: encouraging decomposition
Dark matter: resisting decomposition
@crichardson
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
Generates
SystemOperation()
Collaboration
@crichardson
Simple interactions
Create
Order()
Service
Subdomain
A
Subdomain
B
Service B
Service A
Subdomain
A
Subdomain
B
Create
Order()
Complex distributed
operation
Simple local operation: easier
to understand, troubleshoot, …
vs.
@crichardson
Impact of extracting services on complexity
FTGO Monolith
Delivery
Service
FTGO Monolith
Delivery
Management
createOrder()
…
createOrder()
…
Collaboration
Order
Management
…
Management
Order
Management
…
Management
Might increase
complexity
@crichardson
Ef
fi
cient interactions
Create
Order()
Service
Subdomain
A
Subdomain
B
Service B
Service A
Subdomain
A
Subdomain
B
Create
Order()
Network latency, limited
bandwidth In-memory, fast!
vs.
Must satisfy
SLOs
@crichardson
Impact of extracting services on ef
fi
ciency
FTGO Monolith
Delivery
Service
FTGO Monolith
Delivery
Management
createOrder()
…
createOrder()
…
Collaboration
Order
Management
…
Management
Order
Management
…
Management
Might be too
inef
fi
cient
@crichardson
Prefer ACID over BASE
System
Operation()
Service
Subdomain
A
Subdomain
B
Service B
Service A
Subdomain
A
Subdomain
B
System
Operation()
Distributed, eventually
consistent transaction Simple, Local ACID transaction
vs.
ACID txn ACID txn
ACID txn
@crichardson
Impact of extracting services on transactions
FTGO Monolith
Delivery
Service
FTGO Monolith
Delivery
Management
createOrder()
…
createOrder()
…
Saga
Order
Management
…
Management
Order
Management
…
Management
Might need
compensating
transactions = complex
changes to monolith
1. createOrder() 2. createDelivery()
FAILS
2. rejectOrder()
@crichardson
Minimize runtime coupling
System
Operation()
Service
Subdomain
A
Subdomain
B
Service B
Service A
Subdomain
A
Subdomain
B
System
Operation()
Risk of runtime coupling No runtime coupling: higher
availability, lower latency
vs.
Must satisfy
SLOs
@crichardson
Impact of extracting services on runtime
coupling
FTGO Monolith
Delivery
Service
FTGO Monolith
Delivery
Management
createOrder()
…
createOrder()
…
Collaboration
Order
Management
…
Management
Order
Management
…
Management
Might have
excessive runtime
coupling
@crichardson
Minimize design time coupling
Order
Subdomain
Customer
Subdomain
reserveCredit()
createOrder()
Customer
Order
Design-time coupling
Minimize with careful design
BUT
You can’t always eliminate it
Risk of lock step changes
API
Risk proportional to:
• API instability
• API complexity
• …
@crichardson
Impact of extracting services
on design-time coupling
Monolith and new service might have excessive design-time
coupling
BUT
Experience with monolith = domain expertise = MonolithFirst
Increases likelihood of designing services with stable API
Reduced risk of accidentally creating design-time coupled
services
@crichardson
Consequences of dark matter forces
FTGO
Monolith
Delivery
Service
FTGO
Monolith
Delivery
Management
createOrder()
…
createOrder()
…
Collaboration
Order
Management
…
Management
Order
Management
…
Management
Might not resolve dark matter forces:
Infeasible architecture
Prefer ACID over BASE:
Might need expensive to
implement compensating
transactions in monolith
@crichardson
Summary
Don’t automatically assume you need microservices:
Make the most of your monolith
Improve your process and organization
BUT
An application/organization can outgrow its monolithic architecture
THEREFORE
Incrementally refactor to microservices
Dark energy forces help identify candidate services
Dark matter forces can make extracting a service infeasible or expensive
https://www.nasa.gov/feature/goddard/2019/nasa-s-james-webb-space-telescope-has-been-assembled-for-the-
fi
rst-time
Process
Organization Architecture
@crichardson
@crichardson chris@chrisrichardson.net
adopt.microservices.io
Questions?
1 of 50

Recommended

DDD SoCal: Decompose your monolith: Ten principles for refactoring a monolith... by
DDD SoCal: Decompose your monolith: Ten principles for refactoring a monolith...DDD SoCal: Decompose your monolith: Ten principles for refactoring a monolith...
DDD SoCal: Decompose your monolith: Ten principles for refactoring a monolith...Chris Richardson
7.7K views63 slides
More the merrier: a microservices anti-pattern by
More the merrier: a microservices anti-patternMore the merrier: a microservices anti-pattern
More the merrier: a microservices anti-patternChris Richardson
2.1K views49 slides
Decompose your monolith: strategies for migrating to microservices (Tide) by
Decompose your monolith: strategies for migrating to microservices (Tide)Decompose your monolith: strategies for migrating to microservices (Tide)
Decompose your monolith: strategies for migrating to microservices (Tide)Chris Richardson
490 views66 slides
A pattern language for microservices - June 2021 by
A pattern language for microservices - June 2021 A pattern language for microservices - June 2021
A pattern language for microservices - June 2021 Chris Richardson
2.9K views47 slides
Decompose your monolith: Six principles for refactoring a monolith to microse... by
Decompose your monolith: Six principles for refactoring a monolith to microse...Decompose your monolith: Six principles for refactoring a monolith to microse...
Decompose your monolith: Six principles for refactoring a monolith to microse...Chris Richardson
15.7K views34 slides
JFokus: Cubes, Hexagons, Triangles, and More: Understanding Microservices by
JFokus: Cubes, Hexagons, Triangles, and More: Understanding MicroservicesJFokus: Cubes, Hexagons, Triangles, and More: Understanding Microservices
JFokus: Cubes, Hexagons, Triangles, and More: Understanding MicroservicesChris Richardson
7.1K views66 slides

More Related Content

What's hot

A Pattern Language for Microservices by
A Pattern Language for MicroservicesA Pattern Language for Microservices
A Pattern Language for MicroservicesChris Richardson
2.5K views61 slides
Microservice architecture design principles by
Microservice architecture design principlesMicroservice architecture design principles
Microservice architecture design principlesSanjoy Kumar Roy
3.6K views26 slides
Microservices, Containers, Kubernetes, Kafka, Kanban by
Microservices, Containers, Kubernetes, Kafka, KanbanMicroservices, Containers, Kubernetes, Kafka, Kanban
Microservices, Containers, Kubernetes, Kafka, KanbanAraf Karsh Hamid
2.6K views84 slides
Why Microservice by
Why Microservice Why Microservice
Why Microservice Kelvin Yeung
501 views32 slides
An introduction to Microservices by
An introduction to MicroservicesAn introduction to Microservices
An introduction to MicroservicesCisco DevNet
5.3K views83 slides
Microservices Design Patterns by
Microservices Design PatternsMicroservices Design Patterns
Microservices Design PatternsHaim Michael
201 views35 slides

What's hot(20)

A Pattern Language for Microservices by Chris Richardson
A Pattern Language for MicroservicesA Pattern Language for Microservices
A Pattern Language for Microservices
Chris Richardson2.5K views
Microservice architecture design principles by Sanjoy Kumar Roy
Microservice architecture design principlesMicroservice architecture design principles
Microservice architecture design principles
Sanjoy Kumar Roy3.6K views
Microservices, Containers, Kubernetes, Kafka, Kanban by Araf Karsh Hamid
Microservices, Containers, Kubernetes, Kafka, KanbanMicroservices, Containers, Kubernetes, Kafka, Kanban
Microservices, Containers, Kubernetes, Kafka, Kanban
Araf Karsh Hamid2.6K views
An introduction to Microservices by Cisco DevNet
An introduction to MicroservicesAn introduction to Microservices
An introduction to Microservices
Cisco DevNet5.3K views
Microservices Design Patterns by Haim Michael
Microservices Design PatternsMicroservices Design Patterns
Microservices Design Patterns
Haim Michael201 views
MicroService Architecture by Fred George
MicroService ArchitectureMicroService Architecture
MicroService Architecture
Fred George66.6K views
Designing loosely coupled services by Chris Richardson
Designing loosely coupled servicesDesigning loosely coupled services
Designing loosely coupled services
Chris Richardson10.1K views
MicroServices at Netflix - challenges of scale by Sudhir Tonse
MicroServices at Netflix - challenges of scaleMicroServices at Netflix - challenges of scale
MicroServices at Netflix - challenges of scale
Sudhir Tonse61.3K views
Cloud Architecture - Multi Cloud, Edge, On-Premise by Araf Karsh Hamid
Cloud Architecture - Multi Cloud, Edge, On-PremiseCloud Architecture - Multi Cloud, Edge, On-Premise
Cloud Architecture - Multi Cloud, Edge, On-Premise
Araf Karsh Hamid393 views
Introduction To Microservices by Lalit Kale
Introduction To MicroservicesIntroduction To Microservices
Introduction To Microservices
Lalit Kale1.1K views
Design patterns for microservice architecture by The Software House
Design patterns for microservice architectureDesign patterns for microservice architecture
Design patterns for microservice architecture
The Software House21.9K views
QConPlus 2021: Minimizing Design Time Coupling in a Microservice Architecture by Chris Richardson
QConPlus 2021: Minimizing Design Time Coupling in a Microservice ArchitectureQConPlus 2021: Minimizing Design Time Coupling in a Microservice Architecture
QConPlus 2021: Minimizing Design Time Coupling in a Microservice Architecture
Chris Richardson3.8K views
Microservices Architecture & Testing Strategies by Araf Karsh Hamid
Microservices Architecture & Testing StrategiesMicroservices Architecture & Testing Strategies
Microservices Architecture & Testing Strategies
Araf Karsh Hamid3.1K views
Overview of the Eventuate Tram Customers and Orders application by Chris Richardson
Overview of the Eventuate Tram Customers and Orders applicationOverview of the Eventuate Tram Customers and Orders application
Overview of the Eventuate Tram Customers and Orders application
Chris Richardson1.5K views
Mainframe Possible: Migrating a Mainframe to AWS by Amazon Web Services
Mainframe Possible: Migrating a Mainframe to AWSMainframe Possible: Migrating a Mainframe to AWS
Mainframe Possible: Migrating a Mainframe to AWS
Amazon Web Services2.1K views
Microservice Architecture by Nguyen Tung
Microservice ArchitectureMicroservice Architecture
Microservice Architecture
Nguyen Tung7.1K views

Similar to YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy, Dark Matter Perspective

Dark Energy, Dark Matter and the Microservices Patterns?! by
Dark Energy, Dark Matter and the Microservices Patterns?!Dark Energy, Dark Matter and the Microservices Patterns?!
Dark Energy, Dark Matter and the Microservices Patterns?!Chris Richardson
2.7K views50 slides
#JaxLondon keynote: Developing applications with a microservice architecture by
#JaxLondon keynote: Developing applications with a microservice architecture#JaxLondon keynote: Developing applications with a microservice architecture
#JaxLondon keynote: Developing applications with a microservice architectureChris Richardson
3.3K views63 slides
Developing Applications with a Micro Service Architecture - Chris Richardson by
Developing Applications with a Micro Service Architecture - Chris RichardsonDeveloping Applications with a Micro Service Architecture - Chris Richardson
Developing Applications with a Micro Service Architecture - Chris RichardsonJAXLondon2014
1.3K views63 slides
Microservices - an architecture that enables DevOps (T Systems DevOps day) by
Microservices - an architecture that enables DevOps (T Systems DevOps day)Microservices - an architecture that enables DevOps (T Systems DevOps day)
Microservices - an architecture that enables DevOps (T Systems DevOps day)Chris Richardson
2K views38 slides
#DevNexus202 Decompose your monolith by
#DevNexus202 Decompose your monolith#DevNexus202 Decompose your monolith
#DevNexus202 Decompose your monolithChris Richardson
5.1K views68 slides
Developing applications with a microservice architecture (svcc) by
Developing applications with a microservice architecture (svcc)Developing applications with a microservice architecture (svcc)
Developing applications with a microservice architecture (svcc)Chris Richardson
8.2K views85 slides

Similar to YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy, Dark Matter Perspective(20)

Dark Energy, Dark Matter and the Microservices Patterns?! by Chris Richardson
Dark Energy, Dark Matter and the Microservices Patterns?!Dark Energy, Dark Matter and the Microservices Patterns?!
Dark Energy, Dark Matter and the Microservices Patterns?!
Chris Richardson2.7K views
#JaxLondon keynote: Developing applications with a microservice architecture by Chris Richardson
#JaxLondon keynote: Developing applications with a microservice architecture#JaxLondon keynote: Developing applications with a microservice architecture
#JaxLondon keynote: Developing applications with a microservice architecture
Chris Richardson3.3K views
Developing Applications with a Micro Service Architecture - Chris Richardson by JAXLondon2014
Developing Applications with a Micro Service Architecture - Chris RichardsonDeveloping Applications with a Micro Service Architecture - Chris Richardson
Developing Applications with a Micro Service Architecture - Chris Richardson
JAXLondon20141.3K views
Microservices - an architecture that enables DevOps (T Systems DevOps day) by Chris Richardson
Microservices - an architecture that enables DevOps (T Systems DevOps day)Microservices - an architecture that enables DevOps (T Systems DevOps day)
Microservices - an architecture that enables DevOps (T Systems DevOps day)
Chris Richardson2K views
#DevNexus202 Decompose your monolith by Chris Richardson
#DevNexus202 Decompose your monolith#DevNexus202 Decompose your monolith
#DevNexus202 Decompose your monolith
Chris Richardson5.1K views
Developing applications with a microservice architecture (svcc) by Chris Richardson
Developing applications with a microservice architecture (svcc)Developing applications with a microservice architecture (svcc)
Developing applications with a microservice architecture (svcc)
Chris Richardson8.2K views
Developing applications with a microservice architecture (SVforum, microservi... by Chris Richardson
Developing applications with a microservice architecture (SVforum, microservi...Developing applications with a microservice architecture (SVforum, microservi...
Developing applications with a microservice architecture (SVforum, microservi...
Chris Richardson168.7K views
Microservices + Events + Docker = A Perfect Trio (dockercon) by Chris Richardson
Microservices + Events + Docker = A Perfect Trio (dockercon)Microservices + Events + Docker = A Perfect Trio (dockercon)
Microservices + Events + Docker = A Perfect Trio (dockercon)
Chris Richardson27.7K views
Microservices + Events + Docker = A Perfect Trio by Docker Captain Chris Rich... by Docker, Inc.
Microservices + Events + Docker = A Perfect Trio by Docker Captain Chris Rich...Microservices + Events + Docker = A Perfect Trio by Docker Captain Chris Rich...
Microservices + Events + Docker = A Perfect Trio by Docker Captain Chris Rich...
Docker, Inc.10.7K views
Microservices: Decomposing Applications for Deployability and Scalability (ja... by Chris Richardson
Microservices: Decomposing Applications for Deployability and Scalability (ja...Microservices: Decomposing Applications for Deployability and Scalability (ja...
Microservices: Decomposing Applications for Deployability and Scalability (ja...
Chris Richardson23.7K views
Omnikron webbinar - Microservices: enabling the rapid, frequent, and reliable... by Chris Richardson
Omnikron webbinar - Microservices: enabling the rapid, frequent, and reliable...Omnikron webbinar - Microservices: enabling the rapid, frequent, and reliable...
Omnikron webbinar - Microservices: enabling the rapid, frequent, and reliable...
Chris Richardson858 views
From Monoliths to Services: Grafually paying your Technical Debt by David Litvak Bruno
From Monoliths to Services: Grafually paying your Technical DebtFrom Monoliths to Services: Grafually paying your Technical Debt
From Monoliths to Services: Grafually paying your Technical Debt
David Litvak Bruno423 views
YOW! Perth: Cubes, Hexagons, Triangles, and More: Understanding the Microserv... by Chris Richardson
YOW! Perth: Cubes, Hexagons, Triangles, and More: Understanding the Microserv...YOW! Perth: Cubes, Hexagons, Triangles, and More: Understanding the Microserv...
YOW! Perth: Cubes, Hexagons, Triangles, and More: Understanding the Microserv...
Chris Richardson4.1K views
The microservice architecture: what, why, when and how? by Chris Richardson
The microservice architecture: what, why, when and how?The microservice architecture: what, why, when and how?
The microservice architecture: what, why, when and how?
Chris Richardson1.5K views
Kong Summit 2018 - Microservices: decomposing applications for testability an... by Chris Richardson
Kong Summit 2018 - Microservices: decomposing applications for testability an...Kong Summit 2018 - Microservices: decomposing applications for testability an...
Kong Summit 2018 - Microservices: decomposing applications for testability an...
Chris Richardson90K views
SVCC Microservices: Decomposing Applications for Testability and Deployability by Chris Richardson
SVCC Microservices: Decomposing Applications for Testability and Deployability SVCC Microservices: Decomposing Applications for Testability and Deployability
SVCC Microservices: Decomposing Applications for Testability and Deployability
Chris Richardson1.5K views
TDC2020 - The microservice architecture: enabling rapid, reliable, frequent a... by Chris Richardson
TDC2020 - The microservice architecture: enabling rapid, reliable, frequent a...TDC2020 - The microservice architecture: enabling rapid, reliable, frequent a...
TDC2020 - The microservice architecture: enabling rapid, reliable, frequent a...
Chris Richardson2.9K views
The Reality of Managing Microservices in Your CD Pipeline by DevOps.com
The Reality of Managing Microservices in Your CD PipelineThe Reality of Managing Microservices in Your CD Pipeline
The Reality of Managing Microservices in Your CD Pipeline
DevOps.com230 views
Saturn2017: No such thing as a microservice! by Chris Richardson
Saturn2017: No such thing as a microservice! Saturn2017: No such thing as a microservice!
Saturn2017: No such thing as a microservice!
Chris Richardson1.2K views
Microservices Workshop All Topics Deck 2016 by Adrian Cockcroft
Microservices Workshop All Topics Deck 2016Microservices Workshop All Topics Deck 2016
Microservices Workshop All Topics Deck 2016
Adrian Cockcroft33.4K views

More from Chris Richardson

Dark energy, dark matter and microservice architecture collaboration patterns by
Dark energy, dark matter and microservice architecture collaboration patternsDark energy, dark matter and microservice architecture collaboration patterns
Dark energy, dark matter and microservice architecture collaboration patternsChris Richardson
2.1K views55 slides
Scenarios_and_Architecture_SkillsMatter_April_2022.pdf by
Scenarios_and_Architecture_SkillsMatter_April_2022.pdfScenarios_and_Architecture_SkillsMatter_April_2022.pdf
Scenarios_and_Architecture_SkillsMatter_April_2022.pdfChris Richardson
2.9K views55 slides
Using patterns and pattern languages to make better architectural decisions by
Using patterns and pattern languages to make better architectural decisions Using patterns and pattern languages to make better architectural decisions
Using patterns and pattern languages to make better architectural decisions Chris Richardson
5.7K views48 slides
iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, fr... by
iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, fr...iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, fr...
iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, fr...Chris Richardson
4K views58 slides
Events to the rescue: solving distributed data problems in a microservice arc... by
Events to the rescue: solving distributed data problems in a microservice arc...Events to the rescue: solving distributed data problems in a microservice arc...
Events to the rescue: solving distributed data problems in a microservice arc...Chris Richardson
3.1K views35 slides
Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing micr... by
Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing micr...Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing micr...
Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing micr...Chris Richardson
3.6K views44 slides

More from Chris Richardson(15)

Dark energy, dark matter and microservice architecture collaboration patterns by Chris Richardson
Dark energy, dark matter and microservice architecture collaboration patternsDark energy, dark matter and microservice architecture collaboration patterns
Dark energy, dark matter and microservice architecture collaboration patterns
Chris Richardson2.1K views
Scenarios_and_Architecture_SkillsMatter_April_2022.pdf by Chris Richardson
Scenarios_and_Architecture_SkillsMatter_April_2022.pdfScenarios_and_Architecture_SkillsMatter_April_2022.pdf
Scenarios_and_Architecture_SkillsMatter_April_2022.pdf
Chris Richardson2.9K views
Using patterns and pattern languages to make better architectural decisions by Chris Richardson
Using patterns and pattern languages to make better architectural decisions Using patterns and pattern languages to make better architectural decisions
Using patterns and pattern languages to make better architectural decisions
Chris Richardson5.7K views
iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, fr... by Chris Richardson
iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, fr...iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, fr...
iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, fr...
Chris Richardson4K views
Events to the rescue: solving distributed data problems in a microservice arc... by Chris Richardson
Events to the rescue: solving distributed data problems in a microservice arc...Events to the rescue: solving distributed data problems in a microservice arc...
Events to the rescue: solving distributed data problems in a microservice arc...
Chris Richardson3.1K views
Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing micr... by Chris Richardson
Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing micr...Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing micr...
Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing micr...
Chris Richardson3.6K views
An overview of the Eventuate Platform by Chris Richardson
An overview of the Eventuate PlatformAn overview of the Eventuate Platform
An overview of the Eventuate Platform
Chris Richardson7.6K views
Oracle CodeOne 2019: Descending the Testing Pyramid: Effective Testing Strate... by Chris Richardson
Oracle CodeOne 2019: Descending the Testing Pyramid: Effective Testing Strate...Oracle CodeOne 2019: Descending the Testing Pyramid: Effective Testing Strate...
Oracle CodeOne 2019: Descending the Testing Pyramid: Effective Testing Strate...
Chris Richardson52.3K views
Oracle CodeOne 2019: Decompose Your Monolith: Strategies for Migrating to Mic... by Chris Richardson
Oracle CodeOne 2019: Decompose Your Monolith: Strategies for Migrating to Mic...Oracle CodeOne 2019: Decompose Your Monolith: Strategies for Migrating to Mic...
Oracle CodeOne 2019: Decompose Your Monolith: Strategies for Migrating to Mic...
Chris Richardson9.1K views
MicroCPH - Managing data consistency in a microservice architecture using Sagas by Chris Richardson
MicroCPH - Managing data consistency in a microservice architecture using SagasMicroCPH - Managing data consistency in a microservice architecture using Sagas
MicroCPH - Managing data consistency in a microservice architecture using Sagas
Chris Richardson27.8K views
GotoChgo 2019: Not Just Events: Developing Asynchronous Microservices by Chris Richardson
GotoChgo 2019: Not Just Events: Developing Asynchronous MicroservicesGotoChgo 2019: Not Just Events: Developing Asynchronous Microservices
GotoChgo 2019: Not Just Events: Developing Asynchronous Microservices
Chris Richardson19K views
Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decom... by Chris Richardson
Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decom...Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decom...
Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decom...
Chris Richardson76.5K views
YOW2018 - Events and Commands: Developing Asynchronous Microservices by Chris Richardson
YOW2018 - Events and Commands: Developing Asynchronous MicroservicesYOW2018 - Events and Commands: Developing Asynchronous Microservices
YOW2018 - Events and Commands: Developing Asynchronous Microservices
Chris Richardson3K views
Mucon: Not Just Events: Developing Asynchronous Microservices by Chris Richardson
Mucon: Not Just Events: Developing Asynchronous MicroservicesMucon: Not Just Events: Developing Asynchronous Microservices
Mucon: Not Just Events: Developing Asynchronous Microservices
Chris Richardson106.4K views
OReilly SACON London: Potholes in the road from monolithic hell: Microservice... by Chris Richardson
OReilly SACON London: Potholes in the road from monolithic hell: Microservice...OReilly SACON London: Potholes in the road from monolithic hell: Microservice...
OReilly SACON London: Potholes in the road from monolithic hell: Microservice...
Chris Richardson91.7K views

Recently uploaded

FIMA 2023 Neo4j & FS - Entity Resolution.pptx by
FIMA 2023 Neo4j & FS - Entity Resolution.pptxFIMA 2023 Neo4j & FS - Entity Resolution.pptx
FIMA 2023 Neo4j & FS - Entity Resolution.pptxNeo4j
8 views26 slides
Short_Story_PPT.pdf by
Short_Story_PPT.pdfShort_Story_PPT.pdf
Short_Story_PPT.pdfutkarshsatishkumarsh
5 views16 slides
SAP FOR TYRE INDUSTRY.pdf by
SAP FOR TYRE INDUSTRY.pdfSAP FOR TYRE INDUSTRY.pdf
SAP FOR TYRE INDUSTRY.pdfVirendra Rai, PMP
24 views3 slides
nintendo_64.pptx by
nintendo_64.pptxnintendo_64.pptx
nintendo_64.pptxpaiga02016
5 views7 slides
Agile 101 by
Agile 101Agile 101
Agile 101John Valentino
9 views20 slides
Keep by
KeepKeep
KeepGeniusee
77 views10 slides

Recently uploaded(20)

FIMA 2023 Neo4j & FS - Entity Resolution.pptx by Neo4j
FIMA 2023 Neo4j & FS - Entity Resolution.pptxFIMA 2023 Neo4j & FS - Entity Resolution.pptx
FIMA 2023 Neo4j & FS - Entity Resolution.pptx
Neo4j8 views
DSD-INT 2023 Simulation of Coastal Hydrodynamics and Water Quality in Hong Ko... by Deltares
DSD-INT 2023 Simulation of Coastal Hydrodynamics and Water Quality in Hong Ko...DSD-INT 2023 Simulation of Coastal Hydrodynamics and Water Quality in Hong Ko...
DSD-INT 2023 Simulation of Coastal Hydrodynamics and Water Quality in Hong Ko...
Deltares14 views
DSD-INT 2023 European Digital Twin Ocean and Delft3D FM - Dols by Deltares
DSD-INT 2023 European Digital Twin Ocean and Delft3D FM - DolsDSD-INT 2023 European Digital Twin Ocean and Delft3D FM - Dols
DSD-INT 2023 European Digital Twin Ocean and Delft3D FM - Dols
Deltares9 views
Myths and Facts About Hospice Care: Busting Common Misconceptions by Care Coordinations
Myths and Facts About Hospice Care: Busting Common MisconceptionsMyths and Facts About Hospice Care: Busting Common Misconceptions
Myths and Facts About Hospice Care: Busting Common Misconceptions
Navigating container technology for enhanced security by Niklas Saari by Metosin Oy
Navigating container technology for enhanced security by Niklas SaariNavigating container technology for enhanced security by Niklas Saari
Navigating container technology for enhanced security by Niklas Saari
Metosin Oy14 views
Dev-HRE-Ops - Addressing the _Last Mile DevOps Challenge_ in Highly Regulated... by TomHalpin9
Dev-HRE-Ops - Addressing the _Last Mile DevOps Challenge_ in Highly Regulated...Dev-HRE-Ops - Addressing the _Last Mile DevOps Challenge_ in Highly Regulated...
Dev-HRE-Ops - Addressing the _Last Mile DevOps Challenge_ in Highly Regulated...
TomHalpin96 views
Advanced API Mocking Techniques by Dimpy Adhikary
Advanced API Mocking TechniquesAdvanced API Mocking Techniques
Advanced API Mocking Techniques
Dimpy Adhikary19 views
Headless JS UG Presentation.pptx by Jack Spektor
Headless JS UG Presentation.pptxHeadless JS UG Presentation.pptx
Headless JS UG Presentation.pptx
Jack Spektor8 views
Ports-and-Adapters Architecture for Embedded HMI by Burkhard Stubert
Ports-and-Adapters Architecture for Embedded HMIPorts-and-Adapters Architecture for Embedded HMI
Ports-and-Adapters Architecture for Embedded HMI
Burkhard Stubert21 views
SUGCON ANZ Presentation V2.1 Final.pptx by Jack Spektor
SUGCON ANZ Presentation V2.1 Final.pptxSUGCON ANZ Presentation V2.1 Final.pptx
SUGCON ANZ Presentation V2.1 Final.pptx
Jack Spektor23 views
Gen Apps on Google Cloud PaLM2 and Codey APIs in Action by Márton Kodok
Gen Apps on Google Cloud PaLM2 and Codey APIs in ActionGen Apps on Google Cloud PaLM2 and Codey APIs in Action
Gen Apps on Google Cloud PaLM2 and Codey APIs in Action
Márton Kodok6 views

YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy, Dark Matter Perspective

  • 1. @crichardson Migrating a monolith to microservices? A dark energy, dark matter perspective 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 © 2022. Chris Richardson Consulting, Inc. All rights reserved
  • 3. @crichardson Software is eating the world Business critical application You must deliver software rapidly, frequently, reliably and sustainably You Responsible for S/W VUCA
  • 4. @crichardson Goal Your reality Measured by DORA metrics + your monolith’s technology stack is out of date
  • 5. @crichardson Adopting the microservice architecture will make everything wonderful, right? Hint: it won’t
  • 6. @crichardson Presentation goal Using the dark energy and dark matter forces to decide whether to refactor a monolith to microservices
  • 8. @crichardson Agenda Architecting for modern software delivery Dark energy and dark matter: forces that drive the architecture Dark energy: encouraging decomposition Dark matter: resisting decomposition
  • 9. @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
  • 10. Required architectural quality attributes (.a.k.a. -ilities) DevOps Autonomous Teams Long-lived applications Testability Deployability Loose coupling Evolvability Enable incremental upgrades of technology stack
  • 11. @crichardson Make the most of the monolith Process: adopt DevOps and automate Organization: Restructure and increase autonomy Monolithic architecture: Modularize and modernize Success triangle
  • 12. @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
  • 13. @crichardson On the other hand: Improving the monolith can take a while THEREFORE Implement urgent new features as services now
  • 14. @crichardson Strangler Fig Pattern: Incrementally refactoring a monolith to services 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 Stop/resume at any point When should you migrate? And, which parts?
  • 15. @crichardson Agenda Architecting for modern software delivery Dark energy and dark matter: forces that drive the architecture Dark energy: encouraging decomposition Dark matter: resisting decomposition
  • 16. @crichardson How to de fi ne an Architecture… Application ≪subdomain≫ Customer management ≪aggregate≫ Customer ≪subdomain≫ Order management ≪aggregate≫ Order createCustomer() createOrder() fi ndOrder() fi ndOrderHistory() System operations Distill Requirements The “requests” that the application implements Have SLOs Customer Team Order Team About Subdomains • Business capability/function/etc • Logical view: packages and classes • Team-sized • Loosely coupled (Conways law) 1 2 Functional requirements As a consumer I want to place an Order So that I can …. As a Restaurant I want to accept an Order So that I can …. Event storming Wireframe/UI mockups Available Restaurants Restaurant Menu System quality attributes • SLA: Reliability/Latency • Scalability • …
  • 17. @crichardson Kitchen Service Delivery Service Order Service createOrder() … how to de fi ne an Architecture createOrder() <<subdomain>> Order Management Order System operations <<subdomain>> Order Management <<subdomain>> Kitchen Management <<subdomain>> Delivery Management <<subdomain>> Courier Management Group subdomains into services Application Collaboration Design collaborations for distributed operations createOrder() 3 Monolith or Microservices
  • 18. @crichardson Grouping subdomains into components: together or separate? ≪subdomain≫ Customer ≪aggregate≫ Customer ≪subdomain≫ Order ≪aggregate≫ Order Attraction Repulsion 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, ef fi cient interactions Prefer ACID over BASE Minimize runtime coupling … https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html Generate systemOperation()
  • 19. @crichardson Together or separate = Module vs. Service? FTGO Monolith Delivery Service FTGO Monolith Delivery Management createOrder() VS createOrder() Collaboration Order Management … Management Order Management … Management Dark Energy Dark Matter Bene fi ts Cost & Feasibility
  • 20. @crichardson Agenda Architecting for modern software delivery Dark energy and dark matter: forces that drive the architecture Dark energy: encouraging decomposition Dark matter: resisting decomposition
  • 21. @crichardson Repulsive forces subdomains in different services https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html = reasons to migrate a module into a service 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
  • 23. Simplifying a monolith Modularizing the monolith helps reduce complexity Developer can focus on their module BUT Complexity ∝Size 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 customers. domain customers. web customers. api Module/New Feature → Service = simpler development IF • Module is actively being developed • Monolith is large
  • 24. @crichardson Team autonomy = service per team Service Service Service Subdomain A Subdomain A Subdomain B Subdomain B Coordination required Build, test and deploy independently vs. Team A Team B Team A Team B
  • 25. Monoliths and team autonomy Modularization helps BUT Single code base Autonomy ∝ 1/ # developers 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 Deployment pipeline Production FTGO Application Executable JAR customers. domain customers. web customers. api Module/New Feature → Service = increased autonomy IF • Module is actively being developed • Many teams
  • 26. @crichardson Fast deployment pipeline @mipsytipsy https://speakerdeck.com/charity/cd?slide=17 Service Subdomain Subdomain Service Subdomain Shorter lead time Simpler build Longer lead time More complex build* * Parallelizing building/testing partially helps Service Subdomain vs.
  • 27. @crichardson Optimizing a monolith’s deployment pipeline $ git pull $./gradlew test $ git push ! [rejected] …. Use merge queue Accelerate build/test: • Incremental testing through DIP and ISP • Parallelization/clustered builds • Selective test execution BUT if the application/team keeps growing Then eventually the deployment pipeline = bottleneck Module/New Feature → Service = faster deployment pipeline IF • Module is actively being developed • Monolith is large • Many teams
  • 28. @crichardson Support multiple technology stacks Service Python Service Java Service JVM Subdomain A Subdomain A Subdomain B Subdomain B Single technology stack Upgrade together Separate technology stacks Right tool for the job Upgrade independently Experiment easily versus
  • 29. @crichardson Monolith = single technology stack Single class path unless using exotic technology, eg. Layrry Single version of each dependency => big bang upgrades No opportunity to experiment No possibility of using non-JVM technologies, e.g. Python Module/New Feature → Service = multiple technology stacks
  • 30. @crichardson Separate subdomains by characteristics Subdomain characteristic Issue Resource requirements Cost-effective, scalability Regulations, e.g. SaMD/ PCI DevOps vs. Slower regulated process Business criticality/tier Maximize availability Security, e.g. PII, … Improve security DDD core/supporting/ generic Focus on being competitive
  • 31. @crichardson Cost effective scaling Service Service Service Subdomain A Subdomain A Subdomain B Subdomain B versus CPU MEM GPU Scale together • Wasteful • Costly CPU MEM GPU Scale separately • Ef fi cient • Cheaper Load Load Load Load EC2: p4d.24xlarge EC2: p4d.24xlarge EC2: m5.24xlarge 8x cost!
  • 32. @crichardson Example: Segregate by business criticality Service Service Service Payment Processing Payment Processing Merchant management Merchant management Shared infrastructure Shared code base Risk of interference Separate infrastructure Separate code base Isolated vs. chargeCard() 2.9% + 30c/ request Revenue loss and penalties chargeCard() Critical Important
  • 33. @crichardson Multiple “deployments” can address some requirements FTGO Monolith FTGO Monolith Router chargeCard() ….() SPRING_PROFILES_ACTIVE=…. SPRING_PROFILES_ACTIVE=…. Request BUT not others: • single code base • …. • Scalability • Availability • … Module/New Feature → Service = Improves architecture via separation
  • 34. @crichardson Some parts of your monolith will bene fi t more from microservices e.g. actively being developed => Using dark energy to identify candidate services
  • 35. @crichardson Data science team (Not “hardcore” devs) ML-based Fraud detection Service E-Commerce Monolith Develops Faster deployment pipeline Python technology stack Simpli fi ed development experience Improved autonomy
  • 36. @crichardson Agenda Architecting for modern software delivery Dark energy and dark matter: forces that drive the architecture Dark energy: encouraging decomposition Dark matter: resisting decomposition
  • 37. @crichardson 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 Generates SystemOperation() Collaboration
  • 38. @crichardson Simple interactions Create Order() Service Subdomain A Subdomain B Service B Service A Subdomain A Subdomain B Create Order() Complex distributed operation Simple local operation: easier to understand, troubleshoot, … vs.
  • 39. @crichardson Impact of extracting services on complexity FTGO Monolith Delivery Service FTGO Monolith Delivery Management createOrder() … createOrder() … Collaboration Order Management … Management Order Management … Management Might increase complexity
  • 40. @crichardson Ef fi cient interactions Create Order() Service Subdomain A Subdomain B Service B Service A Subdomain A Subdomain B Create Order() Network latency, limited bandwidth In-memory, fast! vs. Must satisfy SLOs
  • 41. @crichardson Impact of extracting services on ef fi ciency FTGO Monolith Delivery Service FTGO Monolith Delivery Management createOrder() … createOrder() … Collaboration Order Management … Management Order Management … Management Might be too inef fi cient
  • 42. @crichardson Prefer ACID over BASE System Operation() Service Subdomain A Subdomain B Service B Service A Subdomain A Subdomain B System Operation() Distributed, eventually consistent transaction Simple, Local ACID transaction vs. ACID txn ACID txn ACID txn
  • 43. @crichardson Impact of extracting services on transactions FTGO Monolith Delivery Service FTGO Monolith Delivery Management createOrder() … createOrder() … Saga Order Management … Management Order Management … Management Might need compensating transactions = complex changes to monolith 1. createOrder() 2. createDelivery() FAILS 2. rejectOrder()
  • 44. @crichardson Minimize runtime coupling System Operation() Service Subdomain A Subdomain B Service B Service A Subdomain A Subdomain B System Operation() Risk of runtime coupling No runtime coupling: higher availability, lower latency vs. Must satisfy SLOs
  • 45. @crichardson Impact of extracting services on runtime coupling FTGO Monolith Delivery Service FTGO Monolith Delivery Management createOrder() … createOrder() … Collaboration Order Management … Management Order Management … Management Might have excessive runtime coupling
  • 46. @crichardson Minimize design time coupling Order Subdomain Customer Subdomain reserveCredit() createOrder() Customer Order Design-time coupling Minimize with careful design BUT You can’t always eliminate it Risk of lock step changes API Risk proportional to: • API instability • API complexity • …
  • 47. @crichardson Impact of extracting services on design-time coupling Monolith and new service might have excessive design-time coupling BUT Experience with monolith = domain expertise = MonolithFirst Increases likelihood of designing services with stable API Reduced risk of accidentally creating design-time coupled services
  • 48. @crichardson Consequences of dark matter forces FTGO Monolith Delivery Service FTGO Monolith Delivery Management createOrder() … createOrder() … Collaboration Order Management … Management Order Management … Management Might not resolve dark matter forces: Infeasible architecture Prefer ACID over BASE: Might need expensive to implement compensating transactions in monolith
  • 49. @crichardson Summary Don’t automatically assume you need microservices: Make the most of your monolith Improve your process and organization BUT An application/organization can outgrow its monolithic architecture THEREFORE Incrementally refactor to microservices Dark energy forces help identify candidate services Dark matter forces can make extracting a service infeasible or expensive https://www.nasa.gov/feature/goddard/2019/nasa-s-james-webb-space-telescope-has-been-assembled-for-the- fi rst-time Process Organization Architecture