SlideShare a Scribd company logo
@crichardson
Avoiding more the merrier:
a microservices anti-pattern
Chris Richardson
Microservice architecture consultant and trainer
Founder of the original CloudFoundry.com
Author of POJOs in Action and Microservices Patterns
Founder of Eventuate.io
@crichardson
chris@chrisrichardson.net
adopt.microservices.io
Copyright © 2023. Chris Richardson Consulting, Inc. All rights reserved
@crichardson
Presentation goal
How to rightsize your services
and
avoid creating an overly complex,
fi
ne-grained architecture
@crichardson
About Chris
http://adopt.microservices.io
Late 80s 2006 2008 2009
2012-
@crichardson
Agenda
How micro is a microservice?
Designing a microservice architecture
Dark matter forces: reasons to not use services
Dark energy forces: reasons to use services
Microservice architecture
Each service
Independently
deployable
Loosely coupled
Organized around
business capabilities
…
An architectural style that structures the application as a
set of services
@crichardson
But how big is a service?
Microservice architecture
Must be small, right?!
A common conversation
Client: We are having problems testing our services. Can you
help us?
Me: Sure. How many services?
Client: 5
Me: Oh ok. BTW How many developers?
Client: 5
Me: Oh. How about merging into one service?
1 service/developer is remarkably common
@crichardson
Anti-pattern: The more the merrier
Excessively
fi
ne-grained
microservice architecture:
Reduced maintainability,
performance, availability, ….
https://microservices.io/post/antipatterns/2019/05/21/antipattern-more-the-
merrier.html
@crichardson
Agenda
How micro is a microservice?
Designing a microservice architecture
Dark matter forces: reasons to not use services
Dark energy forces: reasons to use services
@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
Subdomains: Eg. Java classes and
packages that implement business logic
Customer Management Order Management
@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
@crichardson
Grouping subdomains into
components: together or separate?
≪subdomain≫
Customer Mgmt.
≪aggregate≫
Customer
≪subdomain≫
Order Mgmt.
≪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
Dark energy and dark matter
forces
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
@crichardson
Let’s imagine you are
implementing Coupons…
Order
Service
<<subdomain>>
Order
Management
Customer
Service
<<subdomain>>
Customer
Management
createCustomer() createOrder()
<<subdomain>>
Coupon
Management
createCoupon(discount, …)
+ couponID
redeem(couponID)
Which service?
reserve
Credit()
@crichardson
Order
Service
Key decision: New service or
existing service?
Coupon
Service
Order
Service
<<subdomain>>
Order
Management
<<subdomain>>
Coupon
Management
Customer
Service
<<subdomain>>
Customer
Management
<<subdomain>>
Order
Management
<<subdomain>>
Coupon
Management
Customer
Service
<<subdomain>>
Customer
Management
OR
Note: Customer+Coupon Service is another option
@crichardson
Agenda
How micro is a microservice?
Designing a microservice architecture
Dark matter forces: reasons to not use services
Dark energy forces: reasons to use services
@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
Generates
SystemOperation()
Collaboration
@crichardson
Dark matter forces: reasons to colocate
Order and Coupon management
Coupon
Service
Order
Service
Order Service
<<subdomain>>
Order
Management
<<subdomain>>
Order
Management
<<subdomain>>
Coupon
Management
<<subdomain>>
Coupon
Management
But do they apply in this situation?
Does de
fi
ning a new service create a problem?
@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
develop, test, understand, troubleshoot,
…
vs.
@crichardson
Question: is each distributed
operation simple?
Additional
interaction
Additional
participant
Minimal increase in complexity but eventually …
@crichardson
Distributed invocations are
expensive
Local method call: customerService.reserveCredit(customerID, amount)
Testing with mock objects
vs.
Distributed invocation:
CustomerServiceProxy
CustomerController
Sagas, compensating transactions, partial failure
Consumer-driven contract tests
…
@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
Question: is each distributed
operation ef
fi
cient enough?
Additional sequential interaction
Minimal reduction in ef
fi
ciency but eventually …
@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
Question: is the distributed
operation “suf
fi
ciently” ACID?
Step Participant Transaction
Compensating
Transaction
1 Order Service createOrder() rejectOrder()
2 Coupon Service redeemCoupon() unredeemCoupon()
3 Customer Service reserveCredit() -
4 Order Service approveOrder() -
Create Order Saga
Doable but much more complex…
@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
Question: does the distributed operation
meet its latency/availability SLO?
All must be available
More available
More complex
Wait
No Wait
@crichardson
Risk: Silo’d teams have dif
fi
culty
identifying excessive runtime coupling
Payment Team:
“We just call the Fraud Service”
Fraud Team: “We have lots of services”
@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
Question: are the two subdomains
suf
fi
ciently design-time decoupled?
interface CouponManagement {
redeemCoupon(couponID, amount)
interface CouponManagement {
redeemCoupon(couponID, amount, orderLineItems)
Not bad ✅
More complex, coupled to order concept ❌
vs.
@crichardson
Agenda
How micro is a microservice?
Designing a microservice architecture
Dark matter forces: reasons to not use services
Dark energy forces: reasons to use services
@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
@crichardson
Dark energy forces: reasons
to create a Coupon Service
Coupon
Service
Order
Service
Order Service
<<subdomain>>
Order
Management
<<subdomain>>
Order
Management
<<subdomain>>
Coupon
Management
<<subdomain>>
Coupon
Management
But do they apply in this situation?
Does de
fi
ning a new service solve a problem?
@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
dependencies
Question: is the Order+Coupon
Service excessively complex?
Coupon management:
reasonably simple, no new
dependencies, …
Minimal additional complexity
Therefore
Separate Coupon Service is not
required
But
If Coupon management
becomes complex then separate
Order Service
main
main
Order Management
orders.web
couponAPI
orders.
domain
Coupon Management
coupons.
persistence
orders.
persistence
Coupon team
Order team
coupons.
domain
coupons.web
coupons.api
Modular Order Service
@crichardson
Team autonomy = service per team
Service
Service
Service
Subdomain
A
Subdomain
A
Subdomain
B
Subdomain
B
Coordination required
Contention for resources
Develop, push, build, test
and deploy independently
vs.
Team A Team B Team A Team B
@crichardson
Question: impact of a single Order
Service on team autonomy?
Who develops Coupon Management?
Orders team
Team autonomy is not an issue
Embed Coupon Management in Order Service
Different team, e.g. Coupons Team:
How much autonomy would they lose?
A few teams = probably ok
But there’s a limit
@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.
Question: Impact of adding Customer
Management to the Order Service?
Increase on test execution time?
testExecutionTime(Coupon
Management)?
Incremental build and test? Worst
case: changing one subdomain
requires testing the other
Increase in commit frequency?
More developers = more commits
Possibility of delays due to queuing
Order Service
main
main
Order Management
orders.web
couponAPI
orders.
domain
Coupon Management
coupons.
persistence
orders.
persistence
coupons.
domain
coupons.web
coupons.api Stable?
@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
Question: does Coupon Management
introduce technology stack issues?
Does Coupon Management use the same technology stack as
Order Management?
Same language, framework
Compatible transitive dependencies
Does Coupon Management introduce new dependencies that
would complicate technology upgrades?
Service upgrade effort proportional # dependencies
A dependency might not support newer versions of libraries,
JDK, etc
@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
Question: How does Coupon
Management compare to Order
Service?
Subdomain characteristic Same?
Resource requirements ✅
Regulations, e.g. SaMD/
PCI
✅
Business criticality/tier ✅
Security, e.g. PII, … ✅
DDD core/supporting/
generic
✅
@crichardson
Summary: designing Coupon Management
Part of Order Service Coupon Service
Dark energy, repulsive forces
Simple components
✅
Doesn’t solve a
problem
Team autonomy
Fast deployment pipeline
Support multiple technology stacks
Segregate by characteristics
Dark matter, attractive forces
Simple interactions
✅
✅❌
Ef
fi
cient interactions ✅
Prefer ACID over BASE ❌
Minimize runtime coupling ❌✅
Minimize design-time coupling ✅
Creates
problems
@crichardson
Summary
Don’t take MICROservices literally
Designing a microservice architecture
Dark energy forces = reasons to use services
Dark matter forces = reasons to not use services
Con
fl
icting forces => must make trade-offs
Implementing subdomains:
JARs by default
As a service to solve a tangible dark energy-related problem
https://www.nasa.gov/feature/goddard/2019/nasa-s-james-webb-space-telescope-has-been-assembled-for-the-
fi
rst-time
@crichardson
@crichardson chris@chrisrichardson.net
adopt.microservices.io
Questions?

More Related Content

What's hot

GotoChgo 2019: Not Just Events: Developing Asynchronous Microservices
GotoChgo 2019: Not Just Events: Developing Asynchronous MicroservicesGotoChgo 2019: Not Just Events: Developing Asynchronous Microservices
GotoChgo 2019: Not Just Events: Developing Asynchronous MicroservicesChris Richardson
 
Micro services Architecture
Micro services ArchitectureMicro services Architecture
Micro services ArchitectureAraf Karsh Hamid
 
Microservice architecture design principles
Microservice architecture design principlesMicroservice architecture design principles
Microservice architecture design principlesSanjoy Kumar Roy
 
An introduction to Microservices
An introduction to MicroservicesAn introduction to Microservices
An introduction to MicroservicesCisco DevNet
 
From Monolithic to Microservices
From Monolithic to Microservices From Monolithic to Microservices
From Monolithic to Microservices Amazon Web Services
 
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...
Kong Summit 2018 - Microservices: decomposing applications for testability an...Chris Richardson
 
QConPlus 2021: Minimizing Design Time Coupling in a Microservice Architecture
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 ArchitectureChris Richardson
 
Service Mesh with Apache Kafka, Kubernetes, Envoy, Istio and Linkerd
Service Mesh with Apache Kafka, Kubernetes, Envoy, Istio and LinkerdService Mesh with Apache Kafka, Kubernetes, Envoy, Istio and Linkerd
Service Mesh with Apache Kafka, Kubernetes, Envoy, Istio and LinkerdKai Wähner
 
JFokus: Cubes, Hexagons, Triangles, and More: Understanding Microservices
JFokus: Cubes, Hexagons, Triangles, and More: Understanding MicroservicesJFokus: Cubes, Hexagons, Triangles, and More: Understanding Microservices
JFokus: Cubes, Hexagons, Triangles, and More: Understanding MicroservicesChris 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?!
Dark Energy, Dark Matter and the Microservices Patterns?!Chris Richardson
 
Kubernetes 101 - an Introduction to Containers, Kubernetes, and OpenShift
Kubernetes 101 - an Introduction to Containers, Kubernetes, and OpenShiftKubernetes 101 - an Introduction to Containers, Kubernetes, and OpenShift
Kubernetes 101 - an Introduction to Containers, Kubernetes, and OpenShiftDevOps.com
 
Api gateway in microservices
Api gateway in microservicesApi gateway in microservices
Api gateway in microservicesKunal Hire
 
Microservices architecture
Microservices architectureMicroservices architecture
Microservices architectureFaren faren
 
Kubernetes Docker Container Implementation Ppt PowerPoint Presentation Slide ...
Kubernetes Docker Container Implementation Ppt PowerPoint Presentation Slide ...Kubernetes Docker Container Implementation Ppt PowerPoint Presentation Slide ...
Kubernetes Docker Container Implementation Ppt PowerPoint Presentation Slide ...SlideTeam
 

What's hot (20)

GotoChgo 2019: Not Just Events: Developing Asynchronous Microservices
GotoChgo 2019: Not Just Events: Developing Asynchronous MicroservicesGotoChgo 2019: Not Just Events: Developing Asynchronous Microservices
GotoChgo 2019: Not Just Events: Developing Asynchronous Microservices
 
Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices
 
Micro services Architecture
Micro services ArchitectureMicro services Architecture
Micro services Architecture
 
Microservice architecture design principles
Microservice architecture design principlesMicroservice architecture design principles
Microservice architecture design principles
 
An introduction to Microservices
An introduction to MicroservicesAn introduction to Microservices
An introduction to Microservices
 
From Monolithic to Microservices
From Monolithic to Microservices From Monolithic to Microservices
From Monolithic to Microservices
 
Istio
Istio Istio
Istio
 
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...
Kong Summit 2018 - Microservices: decomposing applications for testability an...
 
QConPlus 2021: Minimizing Design Time Coupling in a Microservice Architecture
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
 
Service Mesh with Apache Kafka, Kubernetes, Envoy, Istio and Linkerd
Service Mesh with Apache Kafka, Kubernetes, Envoy, Istio and LinkerdService Mesh with Apache Kafka, Kubernetes, Envoy, Istio and Linkerd
Service Mesh with Apache Kafka, Kubernetes, Envoy, Istio and Linkerd
 
Why to Cloud Native
Why to Cloud NativeWhy to Cloud Native
Why to Cloud Native
 
JFokus: Cubes, Hexagons, Triangles, and More: Understanding Microservices
JFokus: Cubes, Hexagons, Triangles, and More: Understanding MicroservicesJFokus: Cubes, Hexagons, Triangles, and More: Understanding Microservices
JFokus: Cubes, Hexagons, Triangles, and More: Understanding Microservices
 
Dark Energy, Dark Matter and the Microservices Patterns?!
Dark Energy, Dark Matter and the Microservices Patterns?!Dark Energy, Dark Matter and the Microservices Patterns?!
Dark Energy, Dark Matter and the Microservices Patterns?!
 
Kubernetes 101 - an Introduction to Containers, Kubernetes, and OpenShift
Kubernetes 101 - an Introduction to Containers, Kubernetes, and OpenShiftKubernetes 101 - an Introduction to Containers, Kubernetes, and OpenShift
Kubernetes 101 - an Introduction to Containers, Kubernetes, and OpenShift
 
Api gateway in microservices
Api gateway in microservicesApi gateway in microservices
Api gateway in microservices
 
Docker Kubernetes Istio
Docker Kubernetes IstioDocker Kubernetes Istio
Docker Kubernetes Istio
 
Microservices architecture
Microservices architectureMicroservices architecture
Microservices architecture
 
Microservice architecture
Microservice architectureMicroservice architecture
Microservice architecture
 
Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices
 
Kubernetes Docker Container Implementation Ppt PowerPoint Presentation Slide ...
Kubernetes Docker Container Implementation Ppt PowerPoint Presentation Slide ...Kubernetes Docker Container Implementation Ppt PowerPoint Presentation Slide ...
Kubernetes Docker Container Implementation Ppt PowerPoint Presentation Slide ...
 

Similar to More the merrier: a microservices anti-pattern

Dark energy, dark matter and microservice architecture collaboration patterns
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
 
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...
Microservices + Events + Docker = A Perfect Trio by Docker Captain Chris Rich...Docker, Inc.
 
Microservices + Events + Docker = A Perfect Trio (dockercon)
Microservices + Events + Docker = A Perfect Trio (dockercon)Microservices + Events + Docker = A Perfect Trio (dockercon)
Microservices + Events + Docker = A Perfect Trio (dockercon)Chris Richardson
 
Saturn 2018: Managing data consistency in a microservice architecture using S...
Saturn 2018: Managing data consistency in a microservice architecture using S...Saturn 2018: Managing data consistency in a microservice architecture using S...
Saturn 2018: Managing data consistency in a microservice architecture using S...Chris Richardson
 
Designing loosely coupled services
Designing loosely coupled servicesDesigning loosely coupled services
Designing loosely coupled servicesChris Richardson
 
YOW2018 - Events and Commands: Developing Asynchronous Microservices
YOW2018 - Events and Commands: Developing Asynchronous MicroservicesYOW2018 - Events and Commands: Developing Asynchronous Microservices
YOW2018 - Events and Commands: Developing Asynchronous MicroservicesChris 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...
Microservices: Decomposing Applications for Deployability and Scalability (ja...Chris Richardson
 
Developing applications with a microservice architecture (svcc)
Developing applications with a microservice architecture (svcc)Developing applications with a microservice architecture (svcc)
Developing applications with a microservice architecture (svcc)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...
Developing applications with a microservice architecture (SVforum, microservi...Chris Richardson
 
JavaOne2017: ACID Is So Yesterday: Maintaining Data Consistency with Sagas
JavaOne2017: ACID Is So Yesterday: Maintaining Data Consistency with SagasJavaOne2017: ACID Is So Yesterday: Maintaining Data Consistency with Sagas
JavaOne2017: ACID Is So Yesterday: Maintaining Data Consistency with SagasChris Richardson
 
Decomposing applications for deployability and scalability(SpringSource webinar)
Decomposing applications for deployability and scalability(SpringSource webinar)Decomposing applications for deployability and scalability(SpringSource webinar)
Decomposing applications for deployability and scalability(SpringSource webinar)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
#JaxLondon keynote: Developing applications with a microservice architectureChris Richardson
 
Developing Applications with a Micro Service Architecture - Chris Richardson
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
 
microXchg: Managing data consistency in a microservice architecture using Sagas
microXchg: Managing data consistency in a microservice architecture using SagasmicroXchg: Managing data consistency in a microservice architecture using Sagas
microXchg: Managing data consistency in a microservice architecture using SagasChris 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...
YOW! Perth: Cubes, Hexagons, Triangles, and More: Understanding the Microserv...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...
Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing micr...Chris Richardson
 
#DevNexus202 Decompose your monolith
#DevNexus202 Decompose your monolith#DevNexus202 Decompose your monolith
#DevNexus202 Decompose your monolithChris Richardson
 
Introduction to MicroServices (Oakjug)
Introduction to MicroServices (Oakjug)Introduction to MicroServices (Oakjug)
Introduction to MicroServices (Oakjug)Chris Richardson
 
Solving distributed data management problems in a microservice architecture (...
Solving distributed data management problems in a microservice architecture (...Solving distributed data management problems in a microservice architecture (...
Solving distributed data management problems in a microservice architecture (...Chris Richardson
 
Evolution of Microservices - Craft Conference
Evolution of Microservices - Craft ConferenceEvolution of Microservices - Craft Conference
Evolution of Microservices - Craft ConferenceAdrian Cockcroft
 

Similar to More the merrier: a microservices anti-pattern (20)

Dark energy, dark matter and microservice architecture collaboration patterns
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
 
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...
Microservices + Events + Docker = A Perfect Trio by Docker Captain Chris Rich...
 
Microservices + Events + Docker = A Perfect Trio (dockercon)
Microservices + Events + Docker = A Perfect Trio (dockercon)Microservices + Events + Docker = A Perfect Trio (dockercon)
Microservices + Events + Docker = A Perfect Trio (dockercon)
 
Saturn 2018: Managing data consistency in a microservice architecture using S...
Saturn 2018: Managing data consistency in a microservice architecture using S...Saturn 2018: Managing data consistency in a microservice architecture using S...
Saturn 2018: Managing data consistency in a microservice architecture using S...
 
Designing loosely coupled services
Designing loosely coupled servicesDesigning loosely coupled services
Designing loosely coupled services
 
YOW2018 - Events and Commands: Developing Asynchronous Microservices
YOW2018 - Events and Commands: Developing Asynchronous MicroservicesYOW2018 - Events and Commands: Developing Asynchronous Microservices
YOW2018 - Events and Commands: Developing Asynchronous Microservices
 
Microservices: Decomposing Applications for Deployability and Scalability (ja...
Microservices: Decomposing Applications for Deployability and Scalability (ja...Microservices: Decomposing Applications for Deployability and Scalability (ja...
Microservices: Decomposing Applications for Deployability and Scalability (ja...
 
Developing applications with a microservice architecture (svcc)
Developing applications with a microservice architecture (svcc)Developing applications with a microservice architecture (svcc)
Developing applications with a microservice architecture (svcc)
 
Developing applications with a microservice architecture (SVforum, microservi...
Developing applications with a microservice architecture (SVforum, microservi...Developing applications with a microservice architecture (SVforum, microservi...
Developing applications with a microservice architecture (SVforum, microservi...
 
JavaOne2017: ACID Is So Yesterday: Maintaining Data Consistency with Sagas
JavaOne2017: ACID Is So Yesterday: Maintaining Data Consistency with SagasJavaOne2017: ACID Is So Yesterday: Maintaining Data Consistency with Sagas
JavaOne2017: ACID Is So Yesterday: Maintaining Data Consistency with Sagas
 
Decomposing applications for deployability and scalability(SpringSource webinar)
Decomposing applications for deployability and scalability(SpringSource webinar)Decomposing applications for deployability and scalability(SpringSource webinar)
Decomposing applications for deployability and scalability(SpringSource webinar)
 
#JaxLondon keynote: Developing applications with a microservice architecture
#JaxLondon keynote: Developing applications with a microservice architecture#JaxLondon keynote: Developing applications with a microservice architecture
#JaxLondon keynote: Developing applications with a microservice architecture
 
Developing Applications with a Micro Service Architecture - Chris Richardson
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
 
microXchg: Managing data consistency in a microservice architecture using Sagas
microXchg: Managing data consistency in a microservice architecture using SagasmicroXchg: Managing data consistency in a microservice architecture using Sagas
microXchg: Managing data consistency in a microservice architecture using Sagas
 
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...
YOW! Perth: Cubes, Hexagons, Triangles, and More: Understanding the Microserv...
 
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...
Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing micr...
 
#DevNexus202 Decompose your monolith
#DevNexus202 Decompose your monolith#DevNexus202 Decompose your monolith
#DevNexus202 Decompose your monolith
 
Introduction to MicroServices (Oakjug)
Introduction to MicroServices (Oakjug)Introduction to MicroServices (Oakjug)
Introduction to MicroServices (Oakjug)
 
Solving distributed data management problems in a microservice architecture (...
Solving distributed data management problems in a microservice architecture (...Solving distributed data management problems in a microservice architecture (...
Solving distributed data management problems in a microservice architecture (...
 
Evolution of Microservices - Craft Conference
Evolution of Microservices - Craft ConferenceEvolution of Microservices - Craft Conference
Evolution of Microservices - Craft Conference
 

More from 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?
The microservice architecture: what, why, when and how?Chris Richardson
 
Scenarios_and_Architecture_SkillsMatter_April_2022.pdf
Scenarios_and_Architecture_SkillsMatter_April_2022.pdfScenarios_and_Architecture_SkillsMatter_April_2022.pdf
Scenarios_and_Architecture_SkillsMatter_April_2022.pdfChris 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
Using patterns and pattern languages to make better architectural decisions 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...
iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, fr...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...
Events to the rescue: solving distributed data problems in a microservice arc...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)
Microservices - an architecture that enables DevOps (T Systems DevOps day)Chris Richardson
 
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...
DDD SoCal: Decompose your monolith: Ten principles for refactoring a monolith...Chris Richardson
 
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...
Decompose your monolith: Six principles for refactoring a monolith to microse...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...
TDC2020 - The microservice architecture: enabling rapid, reliable, frequent a...Chris Richardson
 
Overview of the Eventuate Tram Customers and Orders application
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 applicationChris Richardson
 
An overview of the Eventuate Platform
An overview of the Eventuate PlatformAn overview of the Eventuate Platform
An overview of the Eventuate PlatformChris Richardson
 
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)
Decompose your monolith: strategies for migrating to microservices (Tide)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...
Oracle CodeOne 2019: Descending the Testing Pyramid: Effective Testing Strate...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...
Oracle CodeOne 2019: Decompose Your Monolith: Strategies for Migrating to Mic...Chris Richardson
 
MicroCPH - Managing data consistency in a microservice architecture using Sagas
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 SagasChris 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...
Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decom...Chris Richardson
 
Mucon: Not Just Events: Developing Asynchronous Microservices
Mucon: Not Just Events: Developing Asynchronous MicroservicesMucon: Not Just Events: Developing Asynchronous Microservices
Mucon: Not Just Events: Developing Asynchronous MicroservicesChris 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...
OReilly SACON London: Potholes in the road from monolithic hell: Microservice...Chris Richardson
 

More from Chris Richardson (18)

The microservice architecture: what, why, when and how?
The microservice architecture: what, why, when and how?The microservice architecture: what, why, when and how?
The microservice architecture: what, why, when and how?
 
Scenarios_and_Architecture_SkillsMatter_April_2022.pdf
Scenarios_and_Architecture_SkillsMatter_April_2022.pdfScenarios_and_Architecture_SkillsMatter_April_2022.pdf
Scenarios_and_Architecture_SkillsMatter_April_2022.pdf
 
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
Using patterns and pattern languages to make better architectural decisions
 
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...
iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, fr...
 
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...
Events to the rescue: solving distributed data problems in a microservice arc...
 
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)
Microservices - an architecture that enables DevOps (T Systems DevOps day)
 
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...
DDD SoCal: Decompose your monolith: Ten principles for refactoring a monolith...
 
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...
Decompose your monolith: Six principles for refactoring a monolith to microse...
 
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...
TDC2020 - The microservice architecture: enabling rapid, reliable, frequent a...
 
Overview of the Eventuate Tram Customers and Orders application
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
 
An overview of the Eventuate Platform
An overview of the Eventuate PlatformAn overview of the Eventuate Platform
An overview of the Eventuate Platform
 
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)
Decompose your monolith: strategies for migrating to microservices (Tide)
 
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...
Oracle CodeOne 2019: Descending the Testing Pyramid: Effective Testing Strate...
 
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...
Oracle CodeOne 2019: Decompose Your Monolith: Strategies for Migrating to Mic...
 
MicroCPH - Managing data consistency in a microservice architecture using Sagas
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
 
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...
Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decom...
 
Mucon: Not Just Events: Developing Asynchronous Microservices
Mucon: Not Just Events: Developing Asynchronous MicroservicesMucon: Not Just Events: Developing Asynchronous Microservices
Mucon: Not Just Events: Developing Asynchronous Microservices
 
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...
OReilly SACON London: Potholes in the road from monolithic hell: Microservice...
 

Recently uploaded

JustNaik Solution Deck (stage bus sector)
JustNaik Solution Deck (stage bus sector)JustNaik Solution Deck (stage bus sector)
JustNaik Solution Deck (stage bus sector)Max Lee
 
A Guideline to Gorgias to to Re:amaze Data Migration
A Guideline to Gorgias to to Re:amaze Data MigrationA Guideline to Gorgias to to Re:amaze Data Migration
A Guideline to Gorgias to to Re:amaze Data MigrationHelp Desk Migration
 
GraphSummit Stockholm - Neo4j - Knowledge Graphs and Product Updates
GraphSummit Stockholm - Neo4j - Knowledge Graphs and Product UpdatesGraphSummit Stockholm - Neo4j - Knowledge Graphs and Product Updates
GraphSummit Stockholm - Neo4j - Knowledge Graphs and Product UpdatesNeo4j
 
Crafting the Perfect Measurement Sheet with PLM Integration
Crafting the Perfect Measurement Sheet with PLM IntegrationCrafting the Perfect Measurement Sheet with PLM Integration
Crafting the Perfect Measurement Sheet with PLM IntegrationWave PLM
 
A Python-based approach to data loading in TM1 - Using Airflow as an ETL for TM1
A Python-based approach to data loading in TM1 - Using Airflow as an ETL for TM1A Python-based approach to data loading in TM1 - Using Airflow as an ETL for TM1
A Python-based approach to data loading in TM1 - Using Airflow as an ETL for TM1KnowledgeSeed
 
How To Build a Successful SaaS Design.pdf
How To Build a Successful SaaS Design.pdfHow To Build a Successful SaaS Design.pdf
How To Build a Successful SaaS Design.pdfayushiqss
 
Designing for Privacy in Amazon Web Services
Designing for Privacy in Amazon Web ServicesDesigning for Privacy in Amazon Web Services
Designing for Privacy in Amazon Web ServicesKrzysztofKkol1
 
StrimziCon 2024 - Transition to Apache Kafka on Kubernetes with Strimzi
StrimziCon 2024 - Transition to Apache Kafka on Kubernetes with StrimziStrimziCon 2024 - Transition to Apache Kafka on Kubernetes with Strimzi
StrimziCon 2024 - Transition to Apache Kafka on Kubernetes with Strimzisteffenkarlsson2
 
Advanced Flow Concepts Every Developer Should Know
Advanced Flow Concepts Every Developer Should KnowAdvanced Flow Concepts Every Developer Should Know
Advanced Flow Concepts Every Developer Should KnowPeter Caitens
 
Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...
Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...
Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...Anthony Dahanne
 
GraphAware - Transforming policing with graph-based intelligence analysis
GraphAware - Transforming policing with graph-based intelligence analysisGraphAware - Transforming policing with graph-based intelligence analysis
GraphAware - Transforming policing with graph-based intelligence analysisNeo4j
 
A Comprehensive Appium Guide for Hybrid App Automation Testing.pdf
A Comprehensive Appium Guide for Hybrid App Automation Testing.pdfA Comprehensive Appium Guide for Hybrid App Automation Testing.pdf
A Comprehensive Appium Guide for Hybrid App Automation Testing.pdfkalichargn70th171
 
AI/ML Infra Meetup | ML explainability in Michelangelo
AI/ML Infra Meetup | ML explainability in MichelangeloAI/ML Infra Meetup | ML explainability in Michelangelo
AI/ML Infra Meetup | ML explainability in MichelangeloAlluxio, Inc.
 
10 Essential Software Testing Tools You Need to Know About.pdf
10 Essential Software Testing Tools You Need to Know About.pdf10 Essential Software Testing Tools You Need to Know About.pdf
10 Essential Software Testing Tools You Need to Know About.pdfkalichargn70th171
 
Agnieszka Andrzejewska - BIM School Course in Kraków
Agnieszka Andrzejewska - BIM School Course in KrakówAgnieszka Andrzejewska - BIM School Course in Kraków
Agnieszka Andrzejewska - BIM School Course in Krakówbim.edu.pl
 
Accelerate Enterprise Software Engineering with Platformless
Accelerate Enterprise Software Engineering with PlatformlessAccelerate Enterprise Software Engineering with Platformless
Accelerate Enterprise Software Engineering with PlatformlessWSO2
 
Into the Box 2024 - Keynote Day 2 Slides.pdf
Into the Box 2024 - Keynote Day 2 Slides.pdfInto the Box 2024 - Keynote Day 2 Slides.pdf
Into the Box 2024 - Keynote Day 2 Slides.pdfOrtus Solutions, Corp
 
How to install and activate eGrabber JobGrabber
How to install and activate eGrabber JobGrabberHow to install and activate eGrabber JobGrabber
How to install and activate eGrabber JobGrabbereGrabber
 
INGKA DIGITAL: Linked Metadata by Design
INGKA DIGITAL: Linked Metadata by DesignINGKA DIGITAL: Linked Metadata by Design
INGKA DIGITAL: Linked Metadata by DesignNeo4j
 

Recently uploaded (20)

JustNaik Solution Deck (stage bus sector)
JustNaik Solution Deck (stage bus sector)JustNaik Solution Deck (stage bus sector)
JustNaik Solution Deck (stage bus sector)
 
A Guideline to Gorgias to to Re:amaze Data Migration
A Guideline to Gorgias to to Re:amaze Data MigrationA Guideline to Gorgias to to Re:amaze Data Migration
A Guideline to Gorgias to to Re:amaze Data Migration
 
GraphSummit Stockholm - Neo4j - Knowledge Graphs and Product Updates
GraphSummit Stockholm - Neo4j - Knowledge Graphs and Product UpdatesGraphSummit Stockholm - Neo4j - Knowledge Graphs and Product Updates
GraphSummit Stockholm - Neo4j - Knowledge Graphs and Product Updates
 
Crafting the Perfect Measurement Sheet with PLM Integration
Crafting the Perfect Measurement Sheet with PLM IntegrationCrafting the Perfect Measurement Sheet with PLM Integration
Crafting the Perfect Measurement Sheet with PLM Integration
 
A Python-based approach to data loading in TM1 - Using Airflow as an ETL for TM1
A Python-based approach to data loading in TM1 - Using Airflow as an ETL for TM1A Python-based approach to data loading in TM1 - Using Airflow as an ETL for TM1
A Python-based approach to data loading in TM1 - Using Airflow as an ETL for TM1
 
How To Build a Successful SaaS Design.pdf
How To Build a Successful SaaS Design.pdfHow To Build a Successful SaaS Design.pdf
How To Build a Successful SaaS Design.pdf
 
Designing for Privacy in Amazon Web Services
Designing for Privacy in Amazon Web ServicesDesigning for Privacy in Amazon Web Services
Designing for Privacy in Amazon Web Services
 
StrimziCon 2024 - Transition to Apache Kafka on Kubernetes with Strimzi
StrimziCon 2024 - Transition to Apache Kafka on Kubernetes with StrimziStrimziCon 2024 - Transition to Apache Kafka on Kubernetes with Strimzi
StrimziCon 2024 - Transition to Apache Kafka on Kubernetes with Strimzi
 
Advanced Flow Concepts Every Developer Should Know
Advanced Flow Concepts Every Developer Should KnowAdvanced Flow Concepts Every Developer Should Know
Advanced Flow Concepts Every Developer Should Know
 
Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...
Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...
Paketo Buildpacks : la meilleure façon de construire des images OCI? DevopsDa...
 
GraphAware - Transforming policing with graph-based intelligence analysis
GraphAware - Transforming policing with graph-based intelligence analysisGraphAware - Transforming policing with graph-based intelligence analysis
GraphAware - Transforming policing with graph-based intelligence analysis
 
A Comprehensive Appium Guide for Hybrid App Automation Testing.pdf
A Comprehensive Appium Guide for Hybrid App Automation Testing.pdfA Comprehensive Appium Guide for Hybrid App Automation Testing.pdf
A Comprehensive Appium Guide for Hybrid App Automation Testing.pdf
 
AI/ML Infra Meetup | ML explainability in Michelangelo
AI/ML Infra Meetup | ML explainability in MichelangeloAI/ML Infra Meetup | ML explainability in Michelangelo
AI/ML Infra Meetup | ML explainability in Michelangelo
 
Corporate Management | Session 3 of 3 | Tendenci AMS
Corporate Management | Session 3 of 3 | Tendenci AMSCorporate Management | Session 3 of 3 | Tendenci AMS
Corporate Management | Session 3 of 3 | Tendenci AMS
 
10 Essential Software Testing Tools You Need to Know About.pdf
10 Essential Software Testing Tools You Need to Know About.pdf10 Essential Software Testing Tools You Need to Know About.pdf
10 Essential Software Testing Tools You Need to Know About.pdf
 
Agnieszka Andrzejewska - BIM School Course in Kraków
Agnieszka Andrzejewska - BIM School Course in KrakówAgnieszka Andrzejewska - BIM School Course in Kraków
Agnieszka Andrzejewska - BIM School Course in Kraków
 
Accelerate Enterprise Software Engineering with Platformless
Accelerate Enterprise Software Engineering with PlatformlessAccelerate Enterprise Software Engineering with Platformless
Accelerate Enterprise Software Engineering with Platformless
 
Into the Box 2024 - Keynote Day 2 Slides.pdf
Into the Box 2024 - Keynote Day 2 Slides.pdfInto the Box 2024 - Keynote Day 2 Slides.pdf
Into the Box 2024 - Keynote Day 2 Slides.pdf
 
How to install and activate eGrabber JobGrabber
How to install and activate eGrabber JobGrabberHow to install and activate eGrabber JobGrabber
How to install and activate eGrabber JobGrabber
 
INGKA DIGITAL: Linked Metadata by Design
INGKA DIGITAL: Linked Metadata by DesignINGKA DIGITAL: Linked Metadata by Design
INGKA DIGITAL: Linked Metadata by Design
 

More the merrier: a microservices anti-pattern

  • 1. @crichardson Avoiding more the merrier: a microservices anti-pattern Chris Richardson Microservice architecture consultant and trainer Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns Founder of Eventuate.io @crichardson chris@chrisrichardson.net adopt.microservices.io Copyright © 2023. Chris Richardson Consulting, Inc. All rights reserved
  • 2. @crichardson Presentation goal How to rightsize your services and avoid creating an overly complex, fi ne-grained architecture
  • 4. @crichardson Agenda How micro is a microservice? Designing a microservice architecture Dark matter forces: reasons to not use services Dark energy forces: reasons to use services
  • 5. Microservice architecture Each service Independently deployable Loosely coupled Organized around business capabilities … An architectural style that structures the application as a set of services
  • 6. @crichardson But how big is a service? Microservice architecture Must be small, right?!
  • 7. A common conversation Client: We are having problems testing our services. Can you help us? Me: Sure. How many services? Client: 5 Me: Oh ok. BTW How many developers? Client: 5 Me: Oh. How about merging into one service? 1 service/developer is remarkably common
  • 8. @crichardson Anti-pattern: The more the merrier Excessively fi ne-grained microservice architecture: Reduced maintainability, performance, availability, …. https://microservices.io/post/antipatterns/2019/05/21/antipattern-more-the- merrier.html
  • 9. @crichardson Agenda How micro is a microservice? Designing a microservice architecture Dark matter forces: reasons to not use services Dark energy forces: reasons to use services
  • 10. @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 • …
  • 11. @crichardson Subdomains: Eg. Java classes and packages that implement business logic Customer Management Order Management
  • 12. @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
  • 13. @crichardson Grouping subdomains into components: together or separate? ≪subdomain≫ Customer Mgmt. ≪aggregate≫ Customer ≪subdomain≫ Order Mgmt. ≪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()
  • 14. @crichardson Dark energy and dark matter forces 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
  • 15. @crichardson Let’s imagine you are implementing Coupons… Order Service <<subdomain>> Order Management Customer Service <<subdomain>> Customer Management createCustomer() createOrder() <<subdomain>> Coupon Management createCoupon(discount, …) + couponID redeem(couponID) Which service? reserve Credit()
  • 16. @crichardson Order Service Key decision: New service or existing service? Coupon Service Order Service <<subdomain>> Order Management <<subdomain>> Coupon Management Customer Service <<subdomain>> Customer Management <<subdomain>> Order Management <<subdomain>> Coupon Management Customer Service <<subdomain>> Customer Management OR Note: Customer+Coupon Service is another option
  • 17. @crichardson Agenda How micro is a microservice? Designing a microservice architecture Dark matter forces: reasons to not use services Dark energy forces: reasons to use services
  • 18. @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 Generates SystemOperation() Collaboration
  • 19. @crichardson Dark matter forces: reasons to colocate Order and Coupon management Coupon Service Order Service Order Service <<subdomain>> Order Management <<subdomain>> Order Management <<subdomain>> Coupon Management <<subdomain>> Coupon Management But do they apply in this situation? Does de fi ning a new service create a problem?
  • 20. @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 develop, test, understand, troubleshoot, … vs.
  • 21. @crichardson Question: is each distributed operation simple? Additional interaction Additional participant Minimal increase in complexity but eventually …
  • 22. @crichardson Distributed invocations are expensive Local method call: customerService.reserveCredit(customerID, amount) Testing with mock objects vs. Distributed invocation: CustomerServiceProxy CustomerController Sagas, compensating transactions, partial failure Consumer-driven contract tests …
  • 23. @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
  • 24. @crichardson Question: is each distributed operation ef fi cient enough? Additional sequential interaction Minimal reduction in ef fi ciency but eventually …
  • 25. @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
  • 26. @crichardson Question: is the distributed operation “suf fi ciently” ACID? Step Participant Transaction Compensating Transaction 1 Order Service createOrder() rejectOrder() 2 Coupon Service redeemCoupon() unredeemCoupon() 3 Customer Service reserveCredit() - 4 Order Service approveOrder() - Create Order Saga Doable but much more complex…
  • 27. @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
  • 28. @crichardson Question: does the distributed operation meet its latency/availability SLO? All must be available More available More complex Wait No Wait
  • 29. @crichardson Risk: Silo’d teams have dif fi culty identifying excessive runtime coupling Payment Team: “We just call the Fraud Service” Fraud Team: “We have lots of services”
  • 30. @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 • …
  • 31. @crichardson Question: are the two subdomains suf fi ciently design-time decoupled? interface CouponManagement { redeemCoupon(couponID, amount) interface CouponManagement { redeemCoupon(couponID, amount, orderLineItems) Not bad ✅ More complex, coupled to order concept ❌ vs.
  • 32. @crichardson Agenda How micro is a microservice? Designing a microservice architecture Dark matter forces: reasons to not use services Dark energy forces: reasons to use services
  • 33. @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
  • 34. @crichardson Dark energy forces: reasons to create a Coupon Service Coupon Service Order Service Order Service <<subdomain>> Order Management <<subdomain>> Order Management <<subdomain>> Coupon Management <<subdomain>> Coupon Management But do they apply in this situation? Does de fi ning a new service solve a problem?
  • 35. @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 dependencies
  • 36. Question: is the Order+Coupon Service excessively complex? Coupon management: reasonably simple, no new dependencies, … Minimal additional complexity Therefore Separate Coupon Service is not required But If Coupon management becomes complex then separate Order Service main main Order Management orders.web couponAPI orders. domain Coupon Management coupons. persistence orders. persistence Coupon team Order team coupons. domain coupons.web coupons.api Modular Order Service
  • 37. @crichardson Team autonomy = service per team Service Service Service Subdomain A Subdomain A Subdomain B Subdomain B Coordination required Contention for resources Develop, push, build, test and deploy independently vs. Team A Team B Team A Team B
  • 38. @crichardson Question: impact of a single Order Service on team autonomy? Who develops Coupon Management? Orders team Team autonomy is not an issue Embed Coupon Management in Order Service Different team, e.g. Coupons Team: How much autonomy would they lose? A few teams = probably ok But there’s a limit
  • 39. @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.
  • 40. Question: Impact of adding Customer Management to the Order Service? Increase on test execution time? testExecutionTime(Coupon Management)? Incremental build and test? Worst case: changing one subdomain requires testing the other Increase in commit frequency? More developers = more commits Possibility of delays due to queuing Order Service main main Order Management orders.web couponAPI orders. domain Coupon Management coupons. persistence orders. persistence coupons. domain coupons.web coupons.api Stable?
  • 41. @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
  • 42. @crichardson Question: does Coupon Management introduce technology stack issues? Does Coupon Management use the same technology stack as Order Management? Same language, framework Compatible transitive dependencies Does Coupon Management introduce new dependencies that would complicate technology upgrades? Service upgrade effort proportional # dependencies A dependency might not support newer versions of libraries, JDK, etc
  • 43. @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
  • 44. @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!
  • 45. @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
  • 46. @crichardson Question: How does Coupon Management compare to Order Service? Subdomain characteristic Same? Resource requirements ✅ Regulations, e.g. SaMD/ PCI ✅ Business criticality/tier ✅ Security, e.g. PII, … ✅ DDD core/supporting/ generic ✅
  • 47. @crichardson Summary: designing Coupon Management Part of Order Service Coupon Service Dark energy, repulsive forces Simple components ✅ Doesn’t solve a problem Team autonomy Fast deployment pipeline Support multiple technology stacks Segregate by characteristics Dark matter, attractive forces Simple interactions ✅ ✅❌ Ef fi cient interactions ✅ Prefer ACID over BASE ❌ Minimize runtime coupling ❌✅ Minimize design-time coupling ✅ Creates problems
  • 48. @crichardson Summary Don’t take MICROservices literally Designing a microservice architecture Dark energy forces = reasons to use services Dark matter forces = reasons to not use services Con fl icting forces => must make trade-offs Implementing subdomains: JARs by default As a service to solve a tangible dark energy-related problem https://www.nasa.gov/feature/goddard/2019/nasa-s-james-webb-space-telescope-has-been-assembled-for-the- fi rst-time