SlideShare uma empresa Scribd logo
1 de 50
Baixar para ler offline
@crichardson
Dark energy, dark matter and
the microservice architecture?!
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
COVID work life since March 6th 2020…
@crichardson
“The software architecture of a computing system is the set of structures needed
to reason about the system, which comprise software elements, relations among
them, and properties of both.”
Documenting Software Architectures, Bass et al
Development
• Maintainability
• Testability
• Deployability
• …
Architect
Nonfunctional requirements
Runtime
• Scalability
• Performance
• Availability
• …
Satis
fi
es
De
fi
nes
Architecture
@crichardson
Monolith or Microservices?
In reality: it depends
BUT
On what?
ask Twitter!
@crichardson
Presentation goal
How dark energy and dark matter
help create a better architecture!
@crichardson
About Chris
http://adopt.microservices.io
Late 80s 2006 2008 2009
2012-
@crichardson
Agenda
A pattern language for microservices
Dark energy and dark matter: forces that drive the architecture
Architecting with dark energy and dark matter
@crichardson
Suck/Rock Dichotomy
http://nealford.com/memeagora/2009/08/05/suck-rock-dichotomy.html
@crichardson
Patterns: a better way to
reason about architecture
Reusable solution
to a problem
occurring
in a context
and its consequences
@crichardson
Alternative
Pattern
The structure of a pattern
Pattern
Bene
fi
ts
Drawbacks
Issues
Alternative
Pattern
Patterns
that
address
issues
Context
Problem
Solution
aka the situation
(con
fl
icting) issues/
requirements/etc to
address
Forces
Consequences
predecessor
successor
Pattern language: collection of
related patterns in a domain
http://en.wikipedia.org/wiki/A_Pattern_Language
Access to Water
Promenade
Local townhall
Intimacy gradient
Light on two sides
Alternative
Pattern
Pattern Issues
Alternative
Pattern
Patterns
that
address
issues
predecessor
successor
@crichardson
@crichardson
Pattern
The pattern language guides you
when developing an architecture
Pattern
Pattern
Context
Problem
Forces
Consequences
Pattern
Solution
Issues
Select
Find
applicable
patterns
Repeat
Problem
Context
Updated
context
Sub-
Problem
Matches
Solves
Assess trade-offs
Pattern
Solution
@crichardson
Microservice
architecture
Monolithic
architecture
Bene
fi
ts
Drawbacks
Issues
Context
Problem: what is the application’s architecture?
Solution
Forces
Bene
fi
ts
Drawbacks
Issues
Solution
Application
≪service≫
Order Management
≪module≫
Order REST API
≪module≫
Order Domain
≪module≫
Order Persistence
≪ service ≫
Kitchen Management
≪module≫
Kitchen REST API
≪module≫
Kitchen Domain
≪module≫
Kitchen Persistence
≪service≫
…
Browser
Order
Database
User
API Gateway/BFF
Kitchen
Database
Message
broker
Application.JAR
≪module≫
Order Management
≪module≫
Order REST API
≪module≫
Order Domain
≪module≫
Order Persistence
≪module≫
Kitchen Management
≪module≫
Kitchen REST API
≪module≫
Kitchen Domain
≪module≫
Kitchen Persistence
≪module≫
…
Browser Database
User
Microservices
Monolith
@crichardson
Microservice
architecture
Monolithic
architecture
Bene
fi
ts
Drawbacks
Issues
Context
Problem: what is the application’s architecture?
Solution
Forces
Bene
fi
ts
Drawbacks
Issues
Solution
@crichardson
Microservice
architecture
Monolithic
architecture
Bene
fi
ts
Drawbacks
Issues
Context
Problem: what is the application’s architecture?
Solution
Forces
Bene
fi
ts
Drawbacks
Issues
Solution
@crichardson
Agenda
A pattern language for microservices
Dark energy and dark matter: forces that drive the architecture
Dark energy and dark matter in action: an example
@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
@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
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 matter 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
@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
@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
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
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
Risk of interference
Separate infrastructure
Isolated
vs.
chargeCard()
2.9% + 30c/
request Revenue loss and penalties
chargeCard()
Critical
Important
@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
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
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
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
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
Designing an architecture =
making trade-offs
Con
fl
icting forces
Therefore
Some services/
operations will
have an optimal
design
Others will be
suboptimal but
good enough
Subdomain A
«Aggregate»
X
Subdomain B
«Aggregate»
Y
Service A Service B
Attraction
Simple, 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
Fine-grained services
Monolith
@crichardson
Agenda
A pattern language for microservices
Dark energy and dark matter: forces that drive the architecture
Dark energy and dark matter in action: an example
@crichardson
Classic layered Monolithic architecture
Github Repository
«Gradle Project»
FtgoApplication
«Gradle Subproject»
main
main
«Gradle Subproject»
web
web
.customers
web.orders
«Gradle Subproject»
domain
domain.
customers
domain.
orders
«Gradle Subproject»
persistence
persistence.
customers
persistence.
orders
Customer team
Order team
Deployment pipeline
Production
FTGO
Application
Executable JAR
Technical
layers
@crichardson
Github Repository
«Gradle Project»
FtgoApplication
«Gradle Subproject»
main
main
«Gradle Subproject»
orders
orders.web
«Gradle Subproject»
customerAPI
orders.
domain
«Gradle Subproject»
customers
customers.
persistence
orders.
persistence
Customer team
Order team
Deployment pipeline
Production
FTGO
Application
Executable JAR
customers.
domain
customers.
web
customers.
api
Modular monolith: domain-oriented
De
fi
nes API
Vertical slices/domains
Clear ownership
@crichardson
Monolithic architecture: bene
fi
ts and drawbacks
revisited
Repulsive forces
Simple components ✅ or ❌ ∝1/ size
Team autonomy ✅ or ❌ ∝1/ size
Fast deployment pipeline ✅ or ❌ ∝1/ size
Support multiple technology stacks ❌
Segregate by characteristic ❌
Attractive forces
Simple, ef
fi
cient interactions ✅
Prefer ACID over BASE ✅
Minimize runtime coupling ✅
Minimize design time coupling ✅
Modularization + build technology
enable the Monolithic Architecture to be
used for larger applications
BUT
the application can ultimately outgrow its
architecture when these forces cannot be
resolved
It can’t resolve these forces
@crichardson
Microservice architecture:
Many components
Production
Github Repository
Github Repository
«Gradle project»
orders
orders.web
orders.
domain
«Gradle project»
customers
customers.
persistence
orders.
persistence
Customer team
Order team
Deployment
pipeline
«Executable JAR»
Order
Service
customers.
domain
customers.
web
customers.
main
orders.main
«Executable JAR»
Customer
Service
Deployment
pipeline
«Service Instance»
Order
Service
«Service Instance»
Customer
Service
Inter-service
Communication
@crichardson
Operation => one or more services
Service
Subdomain
Subdomain
API
Gateway
operation()
Collaboration
Aggregate
Service
Subdomain
Subdomain
Aggregate API Composition
Provider
Service
Service
query()
Composer
Provider
Service
Provider
Service
CQRS
Provider
Service
Service
query()
View
Provider
Service
Provider
Service
Event
Event
Event
Service
Service Service
Transaction
Compensating
transaction
Transaction
Compensating
transaction
Transaction
Compensating
transaction
command()
Saga
Collaboration patterns
@crichardson
Microservice architecture: Bene
fi
ts and drawbacks
Repulsive forces
Simple components ✅
Team autonomy ✅
Fast deployment pipeline ✅
Support multiple technology stacks ✅
Segregate by characteristics ✅
Attractive forces
Simple, ef
fi
cient interactions ❌
Prefer ACID over BASE ❌
Minimize runtime coupling ❌
Minimize design-time coupling ❌
Must design services
and collaborations to:
• Maximize bene
fi
ts
• Minimize drawbacks
Potential bene
fi
ts
Potential drawbacks
@crichardson
Designing the Food To Go architecture
Order Service
<<subdomain>>
Order
Management
Restaurant
Service
<<subdomain>>
Restaurant
Management
Kitchen Service
<<subdomain>>
Kitchen
Management
… Service
<<subdomain>>
…
acceptTicket(ticketID, readyBy)
noteAccepted(readyBy)
scheduleDelivery(readyBy)
createOrder(…)
Ranked operations
<<aggregate>>
Ticket
<<subdomain>>
Delivery Management
<<aggregate>>
Delivery
Services
already
de
fi
ned
To group into
services
createOrder(…)
…
@crichardson
Designing acceptTicket()
Kitchen
Service
Kitchen
Management
Ticket
Delivery
Management
Delivery
Kitchen
Service
Kitchen
Management
Delivery
Service
Ticket
Delivery
Management
Delivery
✅ resolves dark matter forces
❌ violates dark energy forces
• Simplicity
• Team autonomy
• …
acceptTicket() acceptTicket()
✅ resolves dark energy forces
• Simplicity
• Team autonomy
• …
⁈ Dark matter forces
Local
Complicated
Complex
Distributed
How to update Ticket and create Delivery?
???
@crichardson
Saga
Classic 2PC/XA
txn
Bene
fi
ts
Drawbacks
Issues
Context
Problem: how to implement a distributed command?
Solution
Forces
Bene
fi
ts
Drawbacks
Issues
Solution
@crichardson
Bene
fi
ts and drawbacks: 2PC vs. Sagas
2PC Saga
Repulsive forces
…
Support multiple technology stacks ❌ ✅
…
Attractive forces
Simple, ef
fi
cient interactions ? ?
Prefer ACID over BASE ✅ ❌
Minimize runtime coupling ❌ ✅
Minimize design-time coupling ? ?
Must design saga to
minimize drawbacks
Saga design determines
resolution of dark matter forces
T1
T2
…
C1
C2
…
Saga design decisions
Saga
Simple, ef
fi
cient interactions
Prefer ACID over Base
Minimize design-time coupling
Step de
fi
nition and ordering
Choreography or orchestration
Select countermeasures
Dark matter
@crichardson
Accept Order saga design
T1: noteAccepted()
T2: scheduleDelivery()
Ticket accepted
acceptOrder()
Ticket events
channel
Kitchen
Service
Delivery
Service
Attractive forces
Simple, ef
fi
cient interactions ✅
Prefer ACID over BASE ✅*
Minimize runtime coupling ✅
Minimize design-time coupling ✅
* ACID-ish
@crichardson
Summary
“Should I do X*?”
“It depends!”
“Depends on what?”
“Dark energy and dark matter forces”
https://www.nasa.gov/feature/goddard/2019/nasa-s-james-webb-space-telescope-has-been-assembled-for-the-
fi
rst-time
* X - related to Microservices
@crichardson
@crichardson chris@chrisrichardson.net
adopt.microservices.io
Questions?

Mais conteúdo relacionado

Mais procurados

AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
Amazon Web Services Korea
 

Mais procurados (20)

Best Practices for Streaming IoT Data with MQTT and Apache Kafka
Best Practices for Streaming IoT Data with MQTT and Apache KafkaBest Practices for Streaming IoT Data with MQTT and Apache Kafka
Best Practices for Streaming IoT Data with MQTT and Apache Kafka
 
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)
 
From Monolithic to Microservices
From Monolithic to Microservices From Monolithic to Microservices
From Monolithic to Microservices
 
Introduction to microservices
Introduction to microservicesIntroduction to microservices
Introduction to microservices
 
Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices
 
Design patterns for microservice architecture
Design patterns for microservice architectureDesign patterns for microservice architecture
Design patterns for microservice architecture
 
MicroService Architecture
MicroService ArchitectureMicroService Architecture
MicroService Architecture
 
Micro services Architecture
Micro services ArchitectureMicro services Architecture
Micro services Architecture
 
YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy...
YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy...YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy...
YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy...
 
Microservices in Practice
Microservices in PracticeMicroservices in Practice
Microservices in Practice
 
A pattern language for microservices (#gluecon #gluecon2016)
A pattern language for microservices (#gluecon #gluecon2016)A pattern language for microservices (#gluecon #gluecon2016)
A pattern language for microservices (#gluecon #gluecon2016)
 
Designing Microservices
Designing MicroservicesDesigning Microservices
Designing Microservices
 
Introduction to Microservices
Introduction to MicroservicesIntroduction to Microservices
Introduction to Microservices
 
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
AWS 클라우드 기반 게임 아키텍처 사례 - AWS Summit Seoul 2017
 
Juraci Paixão Kröhling - All you need to know about OpenTelemetry
Juraci Paixão Kröhling - All you need to know about OpenTelemetryJuraci Paixão Kröhling - All you need to know about OpenTelemetry
Juraci Paixão Kröhling - All you need to know about OpenTelemetry
 
A Pattern Language for Microservices
A Pattern Language for MicroservicesA Pattern Language for Microservices
A Pattern Language for Microservices
 
Event Sourcing & CQRS, Kafka, Rabbit MQ
Event Sourcing & CQRS, Kafka, Rabbit MQEvent Sourcing & CQRS, Kafka, Rabbit MQ
Event Sourcing & CQRS, Kafka, Rabbit MQ
 
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
 
Microservices Architecture - Bangkok 2018
Microservices Architecture - Bangkok 2018Microservices Architecture - Bangkok 2018
Microservices Architecture - Bangkok 2018
 
Brownfield Domain Driven Design
Brownfield Domain Driven DesignBrownfield Domain Driven Design
Brownfield Domain Driven Design
 

Semelhante a Dark Energy, Dark Matter and the Microservices Patterns?!

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
JAXLondon2014
 

Semelhante a Dark Energy, Dark Matter and the Microservices Patterns?! (20)

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...
 
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)
 
SVCC Microservices: Decomposing Applications for Testability and Deployability
SVCC Microservices: Decomposing Applications for Testability and Deployability SVCC Microservices: Decomposing Applications for Testability and Deployability
SVCC Microservices: Decomposing Applications for Testability and Deployability
 
Saturn2017: No such thing as a microservice!
Saturn2017: No such thing as a microservice! Saturn2017: No such thing as a microservice!
Saturn2017: No such thing as a microservice!
 
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...
Omnikron webbinar - Microservices: enabling the rapid, frequent, and reliable...
 
#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
 
More the merrier: a microservices anti-pattern
More the merrier: a microservices anti-patternMore the merrier: a microservices anti-pattern
More the merrier: a microservices anti-pattern
 
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...
 
agile microservices @scaibo
agile microservices @scaiboagile microservices @scaibo
agile microservices @scaibo
 
Oracle Code Sydney - There is no such thing as a microservice!
Oracle Code Sydney - There is no such thing as a microservice! Oracle Code Sydney - There is no such thing as a microservice!
Oracle Code Sydney - There is no such thing as a microservice!
 
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...
 
Microservices Patterns with GoldenGate
Microservices Patterns with GoldenGateMicroservices Patterns with GoldenGate
Microservices Patterns with GoldenGate
 
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
 
Code Freeze 2018: There is no such thing as a microservice!
Code Freeze 2018: There is no such thing as a microservice!Code Freeze 2018: There is no such thing as a microservice!
Code Freeze 2018: There is no such thing as a microservice!
 
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?
 
There is no such thing as a microservice! (oracle code nyc)
There is no such thing as a microservice! (oracle code nyc)There is no such thing as a microservice! (oracle code nyc)
There is no such thing as a microservice! (oracle code nyc)
 
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...
 

Mais de Chris Richardson

Mais de Chris Richardson (15)

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...
 
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
 
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...
 
Designing loosely coupled services
Designing loosely coupled servicesDesigning loosely coupled services
Designing loosely coupled services
 
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)
 
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
 
#DevNexus202 Decompose your monolith
#DevNexus202 Decompose your monolith#DevNexus202 Decompose your monolith
#DevNexus202 Decompose your monolith
 
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...
 
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...
 
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
 
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...
 

Último

Love witchcraft +27768521739 Binding love spell in Sandy Springs, GA |psychic...
Love witchcraft +27768521739 Binding love spell in Sandy Springs, GA |psychic...Love witchcraft +27768521739 Binding love spell in Sandy Springs, GA |psychic...
Love witchcraft +27768521739 Binding love spell in Sandy Springs, GA |psychic...
chiefasafspells
 
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
VictoriaMetrics
 
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
masabamasaba
 
%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...
%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...
%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...
masabamasaba
 
%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...
%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...
%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...
masabamasaba
 

Último (20)

%in Hazyview+277-882-255-28 abortion pills for sale in Hazyview
%in Hazyview+277-882-255-28 abortion pills for sale in Hazyview%in Hazyview+277-882-255-28 abortion pills for sale in Hazyview
%in Hazyview+277-882-255-28 abortion pills for sale in Hazyview
 
Architecture decision records - How not to get lost in the past
Architecture decision records - How not to get lost in the pastArchitecture decision records - How not to get lost in the past
Architecture decision records - How not to get lost in the past
 
Love witchcraft +27768521739 Binding love spell in Sandy Springs, GA |psychic...
Love witchcraft +27768521739 Binding love spell in Sandy Springs, GA |psychic...Love witchcraft +27768521739 Binding love spell in Sandy Springs, GA |psychic...
Love witchcraft +27768521739 Binding love spell in Sandy Springs, GA |psychic...
 
Crypto Cloud Review - How To Earn Up To $500 Per DAY Of Bitcoin 100% On AutoP...
Crypto Cloud Review - How To Earn Up To $500 Per DAY Of Bitcoin 100% On AutoP...Crypto Cloud Review - How To Earn Up To $500 Per DAY Of Bitcoin 100% On AutoP...
Crypto Cloud Review - How To Earn Up To $500 Per DAY Of Bitcoin 100% On AutoP...
 
VTU technical seminar 8Th Sem on Scikit-learn
VTU technical seminar 8Th Sem on Scikit-learnVTU technical seminar 8Th Sem on Scikit-learn
VTU technical seminar 8Th Sem on Scikit-learn
 
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
Large-scale Logging Made Easy: Meetup at Deutsche Bank 2024
 
WSO2CON2024 - It's time to go Platformless
WSO2CON2024 - It's time to go PlatformlessWSO2CON2024 - It's time to go Platformless
WSO2CON2024 - It's time to go Platformless
 
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
%+27788225528 love spells in new york Psychic Readings, Attraction spells,Bri...
 
%in kempton park+277-882-255-28 abortion pills for sale in kempton park
%in kempton park+277-882-255-28 abortion pills for sale in kempton park %in kempton park+277-882-255-28 abortion pills for sale in kempton park
%in kempton park+277-882-255-28 abortion pills for sale in kempton park
 
%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...
%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...
%+27788225528 love spells in Huntington Beach Psychic Readings, Attraction sp...
 
%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...
%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...
%+27788225528 love spells in Colorado Springs Psychic Readings, Attraction sp...
 
Artyushina_Guest lecture_YorkU CS May 2024.pptx
Artyushina_Guest lecture_YorkU CS May 2024.pptxArtyushina_Guest lecture_YorkU CS May 2024.pptx
Artyushina_Guest lecture_YorkU CS May 2024.pptx
 
WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation
WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital TransformationWSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation
WSO2Con2024 - WSO2's IAM Vision: Identity-Led Digital Transformation
 
%in Soweto+277-882-255-28 abortion pills for sale in soweto
%in Soweto+277-882-255-28 abortion pills for sale in soweto%in Soweto+277-882-255-28 abortion pills for sale in soweto
%in Soweto+277-882-255-28 abortion pills for sale in soweto
 
WSO2CON 2024 - Building the API First Enterprise – Running an API Program, fr...
WSO2CON 2024 - Building the API First Enterprise – Running an API Program, fr...WSO2CON 2024 - Building the API First Enterprise – Running an API Program, fr...
WSO2CON 2024 - Building the API First Enterprise – Running an API Program, fr...
 
WSO2CON 2024 - API Management Usage at La Poste and Its Impact on Business an...
WSO2CON 2024 - API Management Usage at La Poste and Its Impact on Business an...WSO2CON 2024 - API Management Usage at La Poste and Its Impact on Business an...
WSO2CON 2024 - API Management Usage at La Poste and Its Impact on Business an...
 
tonesoftg
tonesoftgtonesoftg
tonesoftg
 
AI & Machine Learning Presentation Template
AI & Machine Learning Presentation TemplateAI & Machine Learning Presentation Template
AI & Machine Learning Presentation Template
 
Devoxx UK 2024 - Going serverless with Quarkus, GraalVM native images and AWS...
Devoxx UK 2024 - Going serverless with Quarkus, GraalVM native images and AWS...Devoxx UK 2024 - Going serverless with Quarkus, GraalVM native images and AWS...
Devoxx UK 2024 - Going serverless with Quarkus, GraalVM native images and AWS...
 
WSO2Con204 - Hard Rock Presentation - Keynote
WSO2Con204 - Hard Rock Presentation - KeynoteWSO2Con204 - Hard Rock Presentation - Keynote
WSO2Con204 - Hard Rock Presentation - Keynote
 

Dark Energy, Dark Matter and the Microservices Patterns?!

  • 1. @crichardson Dark energy, dark matter and the microservice architecture?! 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
  • 2. @crichardson COVID work life since March 6th 2020…
  • 3. @crichardson “The software architecture of a computing system is the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both.” Documenting Software Architectures, Bass et al Development • Maintainability • Testability • Deployability • … Architect Nonfunctional requirements Runtime • Scalability • Performance • Availability • … Satis fi es De fi nes Architecture
  • 4. @crichardson Monolith or Microservices? In reality: it depends BUT On what? ask Twitter!
  • 5. @crichardson Presentation goal How dark energy and dark matter help create a better architecture!
  • 7. @crichardson Agenda A pattern language for microservices Dark energy and dark matter: forces that drive the architecture Architecting with dark energy and dark matter
  • 9. @crichardson Patterns: a better way to reason about architecture Reusable solution to a problem occurring in a context and its consequences
  • 10. @crichardson Alternative Pattern The structure of a pattern Pattern Bene fi ts Drawbacks Issues Alternative Pattern Patterns that address issues Context Problem Solution aka the situation (con fl icting) issues/ requirements/etc to address Forces Consequences predecessor successor
  • 11. Pattern language: collection of related patterns in a domain http://en.wikipedia.org/wiki/A_Pattern_Language Access to Water Promenade Local townhall Intimacy gradient Light on two sides Alternative Pattern Pattern Issues Alternative Pattern Patterns that address issues predecessor successor
  • 13. @crichardson Pattern The pattern language guides you when developing an architecture Pattern Pattern Context Problem Forces Consequences Pattern Solution Issues Select Find applicable patterns Repeat Problem Context Updated context Sub- Problem Matches Solves Assess trade-offs Pattern Solution
  • 14. @crichardson Microservice architecture Monolithic architecture Bene fi ts Drawbacks Issues Context Problem: what is the application’s architecture? Solution Forces Bene fi ts Drawbacks Issues Solution Application ≪service≫ Order Management ≪module≫ Order REST API ≪module≫ Order Domain ≪module≫ Order Persistence ≪ service ≫ Kitchen Management ≪module≫ Kitchen REST API ≪module≫ Kitchen Domain ≪module≫ Kitchen Persistence ≪service≫ … Browser Order Database User API Gateway/BFF Kitchen Database Message broker Application.JAR ≪module≫ Order Management ≪module≫ Order REST API ≪module≫ Order Domain ≪module≫ Order Persistence ≪module≫ Kitchen Management ≪module≫ Kitchen REST API ≪module≫ Kitchen Domain ≪module≫ Kitchen Persistence ≪module≫ … Browser Database User Microservices Monolith
  • 15. @crichardson Microservice architecture Monolithic architecture Bene fi ts Drawbacks Issues Context Problem: what is the application’s architecture? Solution Forces Bene fi ts Drawbacks Issues Solution
  • 16. @crichardson Microservice architecture Monolithic architecture Bene fi ts Drawbacks Issues Context Problem: what is the application’s architecture? Solution Forces Bene fi ts Drawbacks Issues Solution
  • 17. @crichardson Agenda A pattern language for microservices Dark energy and dark matter: forces that drive the architecture Dark energy and dark matter in action: an example
  • 18. @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 • …
  • 19. @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
  • 20. @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()
  • 21. @crichardson 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 matter forces
  • 23. @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
  • 24. @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.
  • 25. @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
  • 26. @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
  • 27. @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!
  • 28. @crichardson Example: Segregate by business criticality Service Service Service Payment Processing Payment Processing Merchant management Merchant management Shared infrastructure Risk of interference Separate infrastructure Isolated vs. chargeCard() 2.9% + 30c/ request Revenue loss and penalties chargeCard() Critical Important
  • 29. @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
  • 30. @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.
  • 31. @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
  • 32. @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
  • 33. @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
  • 34. @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 • …
  • 35. @crichardson Designing an architecture = making trade-offs Con fl icting forces Therefore Some services/ operations will have an optimal design Others will be suboptimal but good enough Subdomain A «Aggregate» X Subdomain B «Aggregate» Y Service A Service B Attraction Simple, 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 Fine-grained services Monolith
  • 36. @crichardson Agenda A pattern language for microservices Dark energy and dark matter: forces that drive the architecture Dark energy and dark matter in action: an example
  • 37. @crichardson Classic layered Monolithic architecture Github Repository «Gradle Project» FtgoApplication «Gradle Subproject» main main «Gradle Subproject» web web .customers web.orders «Gradle Subproject» domain domain. customers domain. orders «Gradle Subproject» persistence persistence. customers persistence. orders Customer team Order team Deployment pipeline Production FTGO Application Executable JAR Technical layers
  • 38. @crichardson Github Repository «Gradle Project» FtgoApplication «Gradle Subproject» main main «Gradle Subproject» orders orders.web «Gradle Subproject» customerAPI orders. domain «Gradle Subproject» customers customers. persistence orders. persistence Customer team Order team Deployment pipeline Production FTGO Application Executable JAR customers. domain customers. web customers. api Modular monolith: domain-oriented De fi nes API Vertical slices/domains Clear ownership
  • 39. @crichardson Monolithic architecture: bene fi ts and drawbacks revisited Repulsive forces Simple components ✅ or ❌ ∝1/ size Team autonomy ✅ or ❌ ∝1/ size Fast deployment pipeline ✅ or ❌ ∝1/ size Support multiple technology stacks ❌ Segregate by characteristic ❌ Attractive forces Simple, ef fi cient interactions ✅ Prefer ACID over BASE ✅ Minimize runtime coupling ✅ Minimize design time coupling ✅ Modularization + build technology enable the Monolithic Architecture to be used for larger applications BUT the application can ultimately outgrow its architecture when these forces cannot be resolved It can’t resolve these forces
  • 40. @crichardson Microservice architecture: Many components Production Github Repository Github Repository «Gradle project» orders orders.web orders. domain «Gradle project» customers customers. persistence orders. persistence Customer team Order team Deployment pipeline «Executable JAR» Order Service customers. domain customers. web customers. main orders.main «Executable JAR» Customer Service Deployment pipeline «Service Instance» Order Service «Service Instance» Customer Service Inter-service Communication
  • 41. @crichardson Operation => one or more services Service Subdomain Subdomain API Gateway operation() Collaboration Aggregate Service Subdomain Subdomain Aggregate API Composition Provider Service Service query() Composer Provider Service Provider Service CQRS Provider Service Service query() View Provider Service Provider Service Event Event Event Service Service Service Transaction Compensating transaction Transaction Compensating transaction Transaction Compensating transaction command() Saga Collaboration patterns
  • 42. @crichardson Microservice architecture: Bene fi ts and drawbacks Repulsive forces Simple components ✅ Team autonomy ✅ Fast deployment pipeline ✅ Support multiple technology stacks ✅ Segregate by characteristics ✅ Attractive forces Simple, ef fi cient interactions ❌ Prefer ACID over BASE ❌ Minimize runtime coupling ❌ Minimize design-time coupling ❌ Must design services and collaborations to: • Maximize bene fi ts • Minimize drawbacks Potential bene fi ts Potential drawbacks
  • 43. @crichardson Designing the Food To Go architecture Order Service <<subdomain>> Order Management Restaurant Service <<subdomain>> Restaurant Management Kitchen Service <<subdomain>> Kitchen Management … Service <<subdomain>> … acceptTicket(ticketID, readyBy) noteAccepted(readyBy) scheduleDelivery(readyBy) createOrder(…) Ranked operations <<aggregate>> Ticket <<subdomain>> Delivery Management <<aggregate>> Delivery Services already de fi ned To group into services createOrder(…) …
  • 44. @crichardson Designing acceptTicket() Kitchen Service Kitchen Management Ticket Delivery Management Delivery Kitchen Service Kitchen Management Delivery Service Ticket Delivery Management Delivery ✅ resolves dark matter forces ❌ violates dark energy forces • Simplicity • Team autonomy • … acceptTicket() acceptTicket() ✅ resolves dark energy forces • Simplicity • Team autonomy • … ⁈ Dark matter forces Local Complicated Complex Distributed How to update Ticket and create Delivery? ???
  • 45. @crichardson Saga Classic 2PC/XA txn Bene fi ts Drawbacks Issues Context Problem: how to implement a distributed command? Solution Forces Bene fi ts Drawbacks Issues Solution
  • 46. @crichardson Bene fi ts and drawbacks: 2PC vs. Sagas 2PC Saga Repulsive forces … Support multiple technology stacks ❌ ✅ … Attractive forces Simple, ef fi cient interactions ? ? Prefer ACID over BASE ✅ ❌ Minimize runtime coupling ❌ ✅ Minimize design-time coupling ? ? Must design saga to minimize drawbacks
  • 47. Saga design determines resolution of dark matter forces T1 T2 … C1 C2 … Saga design decisions Saga Simple, ef fi cient interactions Prefer ACID over Base Minimize design-time coupling Step de fi nition and ordering Choreography or orchestration Select countermeasures Dark matter
  • 48. @crichardson Accept Order saga design T1: noteAccepted() T2: scheduleDelivery() Ticket accepted acceptOrder() Ticket events channel Kitchen Service Delivery Service Attractive forces Simple, ef fi cient interactions ✅ Prefer ACID over BASE ✅* Minimize runtime coupling ✅ Minimize design-time coupling ✅ * ACID-ish
  • 49. @crichardson Summary “Should I do X*?” “It depends!” “Depends on what?” “Dark energy and dark matter forces” https://www.nasa.gov/feature/goddard/2019/nasa-s-james-webb-space-telescope-has-been-assembled-for-the- fi rst-time * X - related to Microservices