SlideShare a Scribd company logo

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

Chris Richardson, profile picture
Chris Richardson

The document discusses the microservice architecture, describing its necessity in modern software development for businesses to remain agile and innovative in a rapidly changing environment. It details architectural patterns, migration strategies from monolithic systems to microservices, and outlines principles for effective implementation, such as gradual migration and measuring success through improved metrics. The author emphasizes the importance of making informed decisions around architecture and development processes to enhance software delivery capabilities.

Software
Related topics:
Application Modernization
1 of 59
Downloaded 18 times
1
2
Most read
3
4
5
6
7
8
9
10
11
12
13
Most read
14
Most read
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
@crichardson The microservice architecture: what, why, when and how? Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns @crichardson chris@chrisrichardson.net adopt.microservices.io Copyright © 2023. Chris Richardson Consulting, Inc. All rights reserved
@crichardson About Chris http://adopt.microservices.io Late 80s 2006 2008 2009 2012-
@crichardson About Chris https://chrisrichardson.net/
@crichardson Agenda Developing software for today’s crazy world Architecture patterns for modern software Migrating a monolith to microservices The microservices pattern language is your guide
@crichardson O V I D - 1 9 https://www.ft.com/content/f9356bdc-3102-11ea-a329-0bcf87a328f2 https://www.ft.com/content/3f498e64-1aa6-11ea-97df-cc63de1d73f4 https://techcrunch.com/2019/06/18/the-rise-of-the-gig-economy-helps-london-based-insurtech-zego-to-raise-42m/ Thriving in today’s world Businesses must be nimble, agile and innovate faster Volatile Uncertain Complex Ambiguous
@crichardson Software is eating the world Business critical application You must deliver software rapidly, frequently, reliably and sustainably You Responsible for S/W VUCA
@crichardson Goal Your reality Measured by DORA metrics + your monolith’s technology stack is out of date https://cloud.google.com/devops/state-of-devops
@crichardson O V I D - 1 9 https://www.ft.com/content/f9356bdc-3102-11ea-a329-0bcf87a328f2 https://www.ft.com/content/3f498e64-1aa6-11ea-97df-cc63de1d73f4 https://techcrunch.com/2019/06/18/the-rise-of-the-gig-economy-helps-london-based-insurtech-zego-to-raise-42m/ The success triangle Process: DevOps/Continuous Delivery & Deployment Organization: Network of small, loosely coupled, product teams IT must deliver software rapidly, frequently, reliably and sustainably. Measured by the DORA metrics Businesses must be nimble, agile and innovate faster S/W VUCA Architecture: ??? Supports Supports
@crichardson Monolith or Microservice architecture? In reality: #itDepends BUT On what? ask Twitter!
@crichardson Agenda Developing software for today’s crazy world Architecture patterns for modern software Migrating a monolith to microservices The microservices pattern language is your guide
@crichardson Suck/Rock Dichotomy http://nealford.com/memeagora/2009/08/05/suck-rock-dichotomy.html
@crichardson Patterns: a better way to reason about architecture Reusable solution to a problem occurring in a context and its consequences
@crichardson Alternative Pattern The structure of a pattern Pattern Bene fi ts Drawbacks Issues Alternative Pattern Patterns that address issues Context Problem Solution aka the situation (con fl icting) issues/ requirements/etc to address Forces Consequences predecessor successor
Pattern language: collection of related patterns in a domain http://en.wikipedia.org/wiki/A_Pattern_Language Access to Water Promenade Local townhall Intimacy gradient Light on two sides Alternative Pattern Pattern Issues Alternative Pattern Patterns that address issues predecessor successor
@crichardson Data patterns Communication patterns Application architecture Cross-cutting concerns Security Deployment Maintaining data consistency External API Reliability Discovery Transactional messaging Testing Observability UI Decomposition Database architecture Querying Communication style Copyright © 2023. Chris Richardson Consulting, Inc. All rights reserved. Learn-Build-Assess Microservices http://adopt.microservices.io API gateway Client-side discovery Server-side discovery Service registry Self registration 3rd party registration Multiple Services per host Single Service per Host Service-per- Container Service-per-VM Messaging Remote Procedure Invocation Database per Service Saga Shared database Microservice Chassis Backends for frontends Event sourcing Monolithic architecture Microservice architecture Motivating Pattern Solution Pattern Solution A Solution B General Specific Serverless deployment Circuit Breaker Access Token Domain-specific Externalized configuration Consumer-driven contract test Service Component Test Exception tracking Distributed tracing Audit logging Application metrics Log aggregation Health check API Service deployment platform Server-side page fragment composition Client-side UI composition Decompose by business capability Decompose by subdomain CQRS Transaction log tailing Transactional Outbox Polling publisher API Composition Consumer-side contract test Sidecar Service mesh Aggregate Domain event Log deployments and changes Self-contained Service Service per team Service Template The Microservice Architecture Pattern Language Application patterns Infrastructure patterns Application Infrastructure patterns
@crichardson Pattern The pattern language guides you when developing an architecture Pattern Pattern Context Problem Forces Consequences Pattern Solution Issues Select Find applicable patterns Repeat Problem Context Updated context Sub- Problem Matches Solves Assess trade-offs Pattern Solution
@crichardson Microservice architecture Monolithic architecture Bene fi ts Drawbacks Issues Context Problem: what is the application’s architecture? Solution Forces Bene fi ts Drawbacks Issues Solution Application ≪service≫ Order Management ≪module≫ Order REST API ≪module≫ Order Domain ≪module≫ Order Persistence ≪ service ≫ Kitchen Management ≪module≫ Kitchen REST API ≪module≫ Kitchen Domain ≪module≫ Kitchen Persistence ≪service≫ … Browser Order Database User API Gateway/BFF Kitchen Database Message broker Application.JAR ≪module≫ Order Management ≪module≫ Order REST API ≪module≫ Order Domain ≪module≫ Order Persistence ≪module≫ Kitchen Management ≪module≫ Kitchen REST API ≪module≫ Kitchen Domain ≪module≫ Kitchen Persistence ≪module≫ … Browser Database User Microservices Monolith
@crichardson Microservice architecture Monolithic architecture Bene fi ts Drawbacks Issues Context 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
Fraud Service Customer Service Monolith Problem: how to group subdomains to form services? <<Subdomain>> Order Management <<Subdomain>> Customer Management <<Subdomain>> Fraud Management <<Subdomain>> Fraud Detection Order team Customer team Fraud Team Slices of business functionality a.k.a. business capabilities owns owns owns How to group? <<Subdomain>> Order Management <<Subdomain>> Customer Management <<Subdomain>> Fraud Management <<Subdomain>> Fraud Detection Order Service <<Subdomain>> Order Management <<Subdomain>> Customer Management <<Subdomain>> Fraud Management <<Subdomain>> Fraud Detection …OR…
@crichardson Microservice architecture Monolithic architecture Bene fi ts Drawbacks Issues Context 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 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 https://microservices.io/post/microservices/2021/11/30/dark-matter-dark-energy.html
@crichardson Dark energy repulsive forces subdomains in different services https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html Service Service «Subdomain» A «Aggregate» X «Subdomain» B «Aggregate» Y Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Segregate by characteristics Repulsive dark energy forces Characteristics: • Resource requirements • Regulations, e.g. SaMD/PCI • Business criticality/tier • Security, e.g. PII, … • DDD core/supporting/generic • ...
@crichardson Dark matter attractive forces subdomains in same service https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html Subdomain A «Aggregate» X Subdomain B «Aggregate» Y Service A Service B Simple interactions Efficient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Attractive dark matter forces SystemOperation() Generates
@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 Pattern: monolithic architecture *Or multiple tightly coupled (via database) services The monolithic architecture is an architectural style that structures the application as a single* executable component
@crichardson Github Repository «Gradle Project» FtgoApplication «Gradle Subproject» main main «Gradle Subproject» orders orders.web «Gradle Subproject» customerAPI orders. domain «Gradle Subproject» customers customers. persistence orders. persistence Customer team Order team Deployment pipeline Production FTGO Application Executable JAR customers. domain customers. web customers. api Monolithic architecture (Modular): single component
@crichardson Monolithic architecture: bene fi ts and drawbacks Repulsive forces Simple components ✅ or ❌ ∝1/ size Team autonomy ✅ or ❌ ∝1/ size Fast deployment pipeline ✅ or ❌ ∝1/ size Support multiple technology stacks ❌ Segregate by characteristic ❌ Attractive forces Simple, ef fi cient interactions ✅ Prefer ACID over BASE ✅ Minimize runtime coupling ✅ Minimize design time coupling ✅ Modularization + build technology enable the Monolithic Architecture to be used for larger applications BUT the application can ultimately outgrow its architecture when these forces cannot be resolved It can’t resolve these forces
Pattern: microservice architecture Loosely coupled Independently deployable Implements a business capability Owned by a small team An architectural style that structures an application as a set of deployable/ executable units, a.k.a. services A service is:
@crichardson API What’s a service…? Operations Event Publisher Commands Queries Synchronous REST/gRPC Asynchronous Messaging Events Event Subscriber API Client Invokes Operations Events Service Database Responsibilities Service Name
@crichardson Runtime environment Infrastructure Git repository Application code Infrastructure code … what’s a service? Application code Infrastructure code Deployment pipeline Deployable /executable Service instance Service instance Infrastructure
@crichardson Services are independently deployable https://microservices.io/post/architecture/2022/05/04/microservice-architecture-essentials-deployability.html End-to-end tests Test collaboration with contract tests
@crichardson Services are loosely coupled: runtime coupling Runtime coupling between service A and B is the degree to which the availability of service A is affected by the availability of service B Order Service Customer Service POST /orders 1 PUT /customers/id Response 4 2 3 Order Service Customer Service POST /orders 1 4 2 3 Order Created event Credit Reserved Event Tight: lower availability Loose: higher availability ID partial Outcome ID Outcome https://microservices.io/patterns/decomposition/self-contained-service.html Saga
Loosely coupled: design-time coupling The degree to which service A is forced to change in lock step with service B Caused by direct, indirect and implicit dependencies Lockstep changes: Coordination between teams Reduced productivity Changes to Customer Service affect Order Service Rarely - Loose coupling Often - Tight coupling API Order Service Customer Service reserveCredit() createOrder() Change Change Change https://microservices.io/post/microservices/2021/05/21/qcon-2021-loose-design-time-coupling.html
Design iceberg services Implementation DB API Small, stable API Large, complex implementation Change Visible Invisible https://microservices.io/microservices/2020/02/04/jfokus-geometry-of-microservices.html
Avoid shared database tables Order Service Customer Service Database Customer table Tight design- time/runtime coupling Order Service Customer Service Order database Order table Customer database Customer table APIs only https://microservices.io/patterns/data/database-per-service.html
@crichardson Services implements business capabilities Services are groups of subdomains Services are NOT usually technical functions e.g. Order Data Service Fraud Service Customer Service Order Service <<Subdomain>> Order Management <<Subdomain>> Customer Management <<Subdomain>> Fraud Management <<Subdomain>> Fraud Detection
@crichardson Dark matter A service is owned by a small team… Order team Order Service <<Subdomain>> Order Management Customer team Customer Service <<Subdomain>> Customer Management Order team Order Service <<Subdomain>> Order Management Customer team <<Subdomain>> Customer Management Ensures team autonomy and resolves other dark energy forces Teams can still be mostly autonomous Dark matter https://microservices.io/patterns/decomposition/service-per-team.html https://microservices.io/post/antipatterns/2019/05/21/antipattern-more-the-merrier.html
@crichardson … Owned by a small team Fraud Team Fraud Service <<Subdomain>> Fraud Management Fraud Detection Service <<Subdomain>> Fraud Detection Additional service solves tangible problem, e.g. resolves a dark energy force Java Python
@crichardson Microservice architecture: Bene fi ts and drawbacks Repulsive forces Simple components ✅ Team autonomy ✅ Fast deployment pipeline ✅ Support multiple technology stacks ✅ Segregate by characteristics ✅ Attractive forces Simple, ef fi cient interactions ❌ Prefer ACID over BASE ❌ Minimize runtime coupling ❌ Minimize design-time coupling ❌ Must design services and collaborations to: • Maximize bene fi ts • Minimize drawbacks Potential bene fi ts Potential drawbacks
@crichardson Use the microservice architecture when: Large application and/or development organization Need multiple technology stacks Segregating subdomains by their characteristics is bene fi cial Resource requirements => better scalability Business critically => better availability Regulatory requirements => faster development …
@crichardson Agenda Developing software for today’s crazy world Architecture patterns for modern software Migrating a monolith to microservices The microservices pattern language is your guide
@crichardson Six principles for migrating a monolith to Microservices 1. Make the most of your monolith 2. Adopt microservices for the right reasons 3. Migrate incrementally 4. Begin with the end in mind 5. Migrate high-value modules fi rst 6. Success is improved velocity and reliability https://microservices.io/post/refactoring/2020/07/28/six-principles-for-refactoring-to-microservices.html
@crichardson Principle #1: Make the most of the monolithic architecture If software delivery is slow Optimize development process Improve deployment pipeline = more automation Improve team autonomy Modularize the monolith to enable independent development Eliminate hand-offs and create cross functional teams If technology stack is obsolete modernize to a new monolith …
@crichardson If and only if that is insuf fi cient* then consider migrating to microservices *Large, complex applications developed by a (usually) large team that need to be delivered rapidly, frequently, and reliably
@crichardson Principle #2: Adopt microservices for the right reasons https://microservices.io/post/microservices/2021/11/30/dark-matter-dark-energy.html Service Service «Subdomain» A «Aggregate» X «Subdomain» B «Aggregate» Y Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Segregate by characteristics Repulsive dark energy forces Characteristics: • Resource requirements • Regulations, e.g. SaMD/PCI • Business criticality/tier • Security, e.g. PII, … • DDD core/supporting/generic • ...
@crichardson Principle #3: Begin with the end in mind - de fi ne a target architecture Target architecture Assemblage process http://microservices-assemblage.io/
@crichardson Principle #4: Migrate incrementally Monolith Time Monolith Service Monolith Service Service Monolith Service Service Service Service …. Monolith Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service …. Strangler application The strangler application grows larger over time The monolith shrinks over time Service Service Service Service Service Service Service Service New features https://microservices.io/patterns/refactoring/strangler-application.html
@crichardson Principle #5: Migrate high- value modules fi rst Bene fi t of extraction Ease of extraction High High Low Low Module B Module A Module C Module D Module E
@crichardson Principle #6: Measuring success Success != Number of Microservices Success = Improved DORA metrics: Reduced lead time Increased deployment frequency Reduced changed failure rate Improvements in other -ilities … Anti-pattern: Microservices as the goal https://microservices.io/post/antipatterns/2019/01/14/antipattern-microservices-are-the-goal.html
@crichardson Agenda Developing software for today’s crazy world Architecture patterns for modern software Migrating a monolith to microservices The microservices pattern language is your guide
@crichardson Deciding to use the microservice architecture is just the beginning Deployment De fi ne services Observe UI Communication Test Cross cutting concerns “Data”
@crichardson Data patterns Communication patterns Application architecture Cross-cutting concerns Security Deployment Maintaining data consistency External API Reliability Discovery Transactional messaging Testing Observability UI Decomposition Database architecture Querying Communication style Copyright © 2023. Chris Richardson Consulting, Inc. All rights reserved. Learn-Build-Assess Microservices http://adopt.microservices.io API gateway Client-side discovery Server-side discovery Service registry Self registration 3rd party registration Multiple Services per host Single Service per Host Service-per- Container Service-per-VM Messaging Remote Procedure Invocation Database per Service Saga Shared database Microservice Chassis Backends for frontends Event sourcing Monolithic architecture Microservice architecture Motivating Pattern Solution Pattern Solution A Solution B General Specific Serverless deployment Circuit Breaker Access Token Domain-specific Externalized configuration Consumer-driven contract test Service Component Test Exception tracking Distributed tracing Audit logging Application metrics Log aggregation Health check API Service deployment platform Server-side page fragment composition Client-side UI composition Decompose by business capability Decompose by subdomain CQRS Transaction log tailing Transactional Outbox Polling publisher API Composition Consumer-side contract test Sidecar Service mesh Aggregate Domain event Log deployments and changes Self-contained Service Service per team Service Template The Microservice Architecture Pattern Language Application patterns Infrastructure patterns Application Infrastructure patterns Application Infrastructure Application and Infrastructure
Database architecture Shared database “Simple”, e.g. ACID But creates tight design-time coupling Best avoided Database per service Reduces design-time coupling But potentially more complex, e.g. no ACID transactions between services https://microservices.io/patterns/data/shared-database.html https://microservices.io/patterns/data/database-per-service.html Service Shared database Service Database (Schema) Service Database per service Service Database (Schema) Database (Schema)
@crichardson Database per service => eventually consistent service collaboration patterns API Composition Provider Service Service query() Composer Provider Service Provider Service CQRS Provider Service Service query() View Provider Service Provider Service Event Event Event Service Service Service Transaction Compensating transaction Transaction Compensating transaction Transaction Compensating transaction command() Saga Service Service command() Replica Source Event Command-side replica Commands Queries https://microservices.io/patterns/index.html#data-management
Communication patterns Remote procedure invocation e.g. REST Simple and familiar But results in tight runtime coupling Use carefully Asynchronous messaging e.g. events Loose runtime coupling More complex Preferred https://microservices.io/patterns/index.html#style Service Service Request Response Remote Procedure Invocation Service Service Messaging Message channel
Deployment patterns Numerous options with different trade-offs Use serverless if you can Otherwise, use containers Virtual Machine Service Service per VM Container Service Service per Container Serverless infrastructure Service Serverless Serverless framework
Summary Monolith or microservices? #itDepends The microservices pattern language is your guide Dark energy and dark matter forces drive the design Remember the principles for refactoring to microservices Incrementally refactor a monolith to microservices adopt.microservices.io @crichardson
@crichardson @crichardson chris@chrisrichardson.net adopt.microservices.io Questions?

More Related Content

PDF
Scenarios_and_Architecture_SkillsMatter_April_2022.pdf
Chris Richardson
 
PDF
Oracle CodeOne 2019: Descending the Testing Pyramid: Effective Testing Strate...
Chris Richardson
 
PDF
Decompose your monolith: Six principles for refactoring a monolith to microse...
Chris Richardson
 
PDF
Using patterns and pattern languages to make better architectural decisions
Chris Richardson
 
PDF
领域驱动设计精要 (Domain Driven Design Inside and Outside)
Weijun Zhong
 
PPTX
4+1 View Model of Software Architecture
bashcode
 
PDF
Introduction to Supply Chain Finance
Steve Keifer
 
PPTX
Microservices Architecture Part 2 Event Sourcing and Saga
Araf Karsh Hamid
 
Scenarios_and_Architecture_SkillsMatter_April_2022.pdf
Chris Richardson
 
Oracle CodeOne 2019: Descending the Testing Pyramid: Effective Testing Strate...
Chris Richardson
 
Decompose your monolith: Six principles for refactoring a monolith to microse...
Chris Richardson
 
Using patterns and pattern languages to make better architectural decisions
Chris Richardson
 
领域驱动设计精要 (Domain Driven Design Inside and Outside)
Weijun Zhong
 
4+1 View Model of Software Architecture
bashcode
 
Introduction to Supply Chain Finance
Steve Keifer
 
Microservices Architecture Part 2 Event Sourcing and Saga
Araf Karsh Hamid
 

What's hot (20)

PDF
Why Microservice
Kelvin Yeung
 
PDF
More the merrier: a microservices anti-pattern
Chris Richardson
 
PPTX
Introduction To Microservices
Lalit Kale
 
PPSX
Domain Driven Design
Araf Karsh Hamid
 
PDF
Designing loosely coupled services
Chris Richardson
 
PDF
Microservices architecture
Abdelghani Azri
 
PPTX
Introduction to microservices
Paulo Gandra de Sousa
 
PPTX
Introduction to Microservices
Roger van de Kimmenade
 
PPTX
MSA ( Microservices Architecture ) 발표 자료 다운로드
Opennaru, inc.
 
PPTX
Microservices
SmartBear
 
PPTX
Domain Driven Design - Strategic Patterns and Microservices
Radosław Maziarka
 
PDF
Microservices with Java, Spring Boot and Spring Cloud
Eberhard Wolff
 
PPSX
Cloud Architecture - Multi Cloud, Edge, On-Premise
Araf Karsh Hamid
 
PDF
Architecture for Flow w/ Wardley Mapping, Domain-Driven Design, and Team Topo...
Susanne Kaiser
 
PPTX
Introduction to Modern Software Architecture
Jérôme Kehrli
 
PDF
A Pattern Language for Microservices
Chris Richardson
 
PDF
Escaping Dependency Hell: A deep dive into Gradle's dependency management fea...
Roberto Pérez Alcolea
 
PDF
Microservice Architecture
tyrantbrian
 
PPTX
VMware Tanzu Kubernetes Connect
VMware Tanzu
 
PPSX
Event Sourcing & CQRS, Kafka, Rabbit MQ
Araf Karsh Hamid
 
Why Microservice
Kelvin Yeung
 
More the merrier: a microservices anti-pattern
Chris Richardson
 
Introduction To Microservices
Lalit Kale
 
Domain Driven Design
Araf Karsh Hamid
 
Designing loosely coupled services
Chris Richardson
 
Microservices architecture
Abdelghani Azri
 
Introduction to microservices
Paulo Gandra de Sousa
 
Introduction to Microservices
Roger van de Kimmenade
 
MSA ( Microservices Architecture ) 발표 자료 다운로드
Opennaru, inc.
 
Microservices
SmartBear
 
Domain Driven Design - Strategic Patterns and Microservices
Radosław Maziarka
 
Microservices with Java, Spring Boot and Spring Cloud
Eberhard Wolff
 
Cloud Architecture - Multi Cloud, Edge, On-Premise
Araf Karsh Hamid
 
Architecture for Flow w/ Wardley Mapping, Domain-Driven Design, and Team Topo...
Susanne Kaiser
 
Introduction to Modern Software Architecture
Jérôme Kehrli
 
A Pattern Language for Microservices
Chris Richardson
 
Escaping Dependency Hell: A deep dive into Gradle's dependency management fea...
Roberto Pérez Alcolea
 
Microservice Architecture
tyrantbrian
 
VMware Tanzu Kubernetes Connect
VMware Tanzu
 
Event Sourcing & CQRS, Kafka, Rabbit MQ
Araf Karsh Hamid
 
Ad

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

PDF
A pattern language for microservices - June 2021
Chris Richardson
 
PDF
Code Freeze 2018: There is no such thing as a microservice!
Chris Richardson
 
PDF
A pattern language for microservices
VMware Tanzu
 
PDF
Microservices pattern language (microxchg microxchg2016)
Chris Richardson
 
PDF
A pattern language for microservices (melbourne)
Chris Richardson
 
PDF
Spring Days NYC - A pattern language for microservices
Chris Richardson
 
PDF
Omnikron webbinar - Microservices: enabling the rapid, frequent, and reliable...
Chris Richardson
 
PDF
Saturn2017: No such thing as a microservice!
Chris Richardson
 
PDF
Oracle Code Sydney - There is no such thing as a microservice!
Chris Richardson
 
PDF
Kong Summit 2018 - Microservices: decomposing applications for testability an...
Chris Richardson
 
PDF
A pattern language for microservices - Chris Richardson
JAXLondon_Conference
 
PDF
There is no such thing as a microservice! (oracle code nyc)
Chris Richardson
 
PDF
A pattern language for microservices (#gluecon #gluecon2016)
Chris Richardson
 
PDF
Dark Energy, Dark Matter and the Microservices Patterns?!
Chris Richardson
 
PDF
A Pattern Language for Microservices (@futurestack)
Chris Richardson
 
PDF
SVCC Microservices: Decomposing Applications for Testability and Deployability
Chris Richardson
 
PDF
RedisConf17 - A pattern language for microservices - Chris Richardson
Redis Labs
 
PPSX
Microservices Architecture, Monolith Migration Patterns
Araf Karsh Hamid
 
PDF
TDC2020 - The microservice architecture: enabling rapid, reliable, frequent a...
Chris Richardson
 
PDF
Decompose your monolith: strategies for migrating to microservices (Tide)
Chris Richardson
 
A pattern language for microservices - June 2021
Chris Richardson
 
Code Freeze 2018: There is no such thing as a microservice!
Chris Richardson
 
A pattern language for microservices
VMware Tanzu
 
Microservices pattern language (microxchg microxchg2016)
Chris Richardson
 
A pattern language for microservices (melbourne)
Chris Richardson
 
Spring Days NYC - A pattern language for microservices
Chris Richardson
 
Omnikron webbinar - Microservices: enabling the rapid, frequent, and reliable...
Chris Richardson
 
Saturn2017: No such thing as a microservice!
Chris Richardson
 
Oracle Code Sydney - There is no such thing as a microservice!
Chris Richardson
 
Kong Summit 2018 - Microservices: decomposing applications for testability an...
Chris Richardson
 
A pattern language for microservices - Chris Richardson
JAXLondon_Conference
 
There is no such thing as a microservice! (oracle code nyc)
Chris Richardson
 
A pattern language for microservices (#gluecon #gluecon2016)
Chris Richardson
 
Dark Energy, Dark Matter and the Microservices Patterns?!
Chris Richardson
 
A Pattern Language for Microservices (@futurestack)
Chris Richardson
 
SVCC Microservices: Decomposing Applications for Testability and Deployability
Chris Richardson
 
RedisConf17 - A pattern language for microservices - Chris Richardson
Redis Labs
 
Microservices Architecture, Monolith Migration Patterns
Araf Karsh Hamid
 
TDC2020 - The microservice architecture: enabling rapid, reliable, frequent a...
Chris Richardson
 
Decompose your monolith: strategies for migrating to microservices (Tide)
Chris Richardson
 
Ad

More from Chris Richardson (20)

PDF
YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy...
Chris Richardson
 
PDF
Dark energy, dark matter and microservice architecture collaboration patterns
Chris Richardson
 
PDF
iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, fr...
Chris Richardson
 
PDF
Events to the rescue: solving distributed data problems in a microservice arc...
Chris Richardson
 
PDF
QConPlus 2021: Minimizing Design Time Coupling in a Microservice Architecture
Chris Richardson
 
PDF
Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing micr...
Chris Richardson
 
PDF
Microservices - an architecture that enables DevOps (T Systems DevOps day)
Chris Richardson
 
PDF
DDD SoCal: Decompose your monolith: Ten principles for refactoring a monolith...
Chris Richardson
 
PDF
Overview of the Eventuate Tram Customers and Orders application
Chris Richardson
 
PDF
An overview of the Eventuate Platform
Chris Richardson
 
PDF
#DevNexus202 Decompose your monolith
Chris Richardson
 
PDF
JFokus: Cubes, Hexagons, Triangles, and More: Understanding Microservices
Chris Richardson
 
PDF
Oracle CodeOne 2019: Decompose Your Monolith: Strategies for Migrating to Mic...
Chris Richardson
 
PDF
YOW! Perth: Cubes, Hexagons, Triangles, and More: Understanding the Microserv...
Chris Richardson
 
PDF
MicroCPH - Managing data consistency in a microservice architecture using Sagas
Chris Richardson
 
PDF
GotoChgo 2019: Not Just Events: Developing Asynchronous Microservices
Chris Richardson
 
PDF
Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decom...
Chris Richardson
 
PDF
YOW2018 - Events and Commands: Developing Asynchronous Microservices
Chris Richardson
 
PDF
Mucon: Not Just Events: Developing Asynchronous Microservices
Chris Richardson
 
PDF
OReilly SACON London: Potholes in the road from monolithic hell: Microservice...
Chris Richardson
 
YOW London - Considering Migrating a Monolith to Microservices? A Dark Energy...
Chris Richardson
 
Dark energy, dark matter and microservice architecture collaboration patterns
Chris Richardson
 
iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, fr...
Chris Richardson
 
Events to the rescue: solving distributed data problems in a microservice arc...
Chris Richardson
 
QConPlus 2021: Minimizing Design Time Coupling in a Microservice Architecture
Chris Richardson
 
Mucon 2021 - Dark energy, dark matter: imperfect metaphors for designing micr...
Chris Richardson
 
Microservices - an architecture that enables DevOps (T Systems DevOps day)
Chris Richardson
 
DDD SoCal: Decompose your monolith: Ten principles for refactoring a monolith...
Chris Richardson
 
Overview of the Eventuate Tram Customers and Orders application
Chris Richardson
 
An overview of the Eventuate Platform
Chris Richardson
 
#DevNexus202 Decompose your monolith
Chris Richardson
 
JFokus: Cubes, Hexagons, Triangles, and More: Understanding Microservices
Chris Richardson
 
Oracle CodeOne 2019: Decompose Your Monolith: Strategies for Migrating to Mic...
Chris Richardson
 
YOW! Perth: Cubes, Hexagons, Triangles, and More: Understanding the Microserv...
Chris Richardson
 
MicroCPH - Managing data consistency in a microservice architecture using Sagas
Chris Richardson
 
GotoChgo 2019: Not Just Events: Developing Asynchronous Microservices
Chris Richardson
 
Melbourne Jan 2019 - Microservices adoption anti-patterns: Obstacles to decom...
Chris Richardson
 
YOW2018 - Events and Commands: Developing Asynchronous Microservices
Chris Richardson
 
Mucon: Not Just Events: Developing Asynchronous Microservices
Chris Richardson
 
OReilly SACON London: Potholes in the road from monolithic hell: Microservice...
Chris Richardson
 

Recently uploaded (20)

PPTX
ManageIQ - Sprint 268 Review - Slide Deck
ManageIQ
 
PDF
Which alternative to Crystal Reports is best for small or large businesses.pdf
Varsha Nayak
 
PDF
Upgrade and Innovation Strategies for SAP ERP Customers
Virendra Rai, PMP
 
PPTX
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
mhxyzzp
 
PDF
System and Network Administration Chapter 2
jaramharo
 
PDF
Odoo Companies in India – Driving Business Transformation.pdf
azhuhardeen1968
 
PPTX
history of c programming in notes for students .pptx
Vijayakumari829030
 
PDF
AI in Product Development-omnex systems
omnex systems
 
PDF
Design an Analysis of Algorithms I-SECS-1021-03
DilanEscobar1
 
PPTX
ISO 45001 Occupational Health and Safety Management System
EHA Soft Solutions
 
PDF
Wondershare Filmora 15 Crack With Activation Key [2025
ghrom2211g
 
PDF
2025 Textile ERP Trends: SAP, Odoo & Oracle
Aetos Technologies
 
PPTX
Oracle E-Business Suite: A Comprehensive Guide for Modern Enterprises
Conacent Consulting
 
PDF
How to Migrate SBCGlobal Email to Yahoo Easily
raymondjones7273
 
PDF
How to Choose the Right IT Partner for Your Business in Malaysia
Asian Business Services & Technologies
 
PDF
Understanding Forklifts - TECH EHS Solution
TECH EHS Solution
 
PPTX
CHAPTER 12 - CYBER SECURITY AND FUTURE SKILLS (1) (1).pptx
AnujKumar530915
 
PDF
Digital Strategies for Manufacturing Companies
Virendra Rai, PMP
 
PDF
System and Network Administraation Chapter 3
jaramharo
 
PDF
SAP S4 Hana Brochure 3 (PTS SYSTEMS AND SOLUTIONS)
pts464036
 
ManageIQ - Sprint 268 Review - Slide Deck
ManageIQ
 
Which alternative to Crystal Reports is best for small or large businesses.pdf
Varsha Nayak
 
Upgrade and Innovation Strategies for SAP ERP Customers
Virendra Rai, PMP
 
Agentic AI Use Case- Contract Lifecycle Management (CLM).pptx
mhxyzzp
 
System and Network Administration Chapter 2
jaramharo
 
Odoo Companies in India – Driving Business Transformation.pdf
azhuhardeen1968
 
history of c programming in notes for students .pptx
Vijayakumari829030
 
AI in Product Development-omnex systems
omnex systems
 
Design an Analysis of Algorithms I-SECS-1021-03
DilanEscobar1
 
ISO 45001 Occupational Health and Safety Management System
EHA Soft Solutions
 
Wondershare Filmora 15 Crack With Activation Key [2025
ghrom2211g
 
2025 Textile ERP Trends: SAP, Odoo & Oracle
Aetos Technologies
 
Oracle E-Business Suite: A Comprehensive Guide for Modern Enterprises
Conacent Consulting
 
How to Migrate SBCGlobal Email to Yahoo Easily
raymondjones7273
 
How to Choose the Right IT Partner for Your Business in Malaysia
Asian Business Services & Technologies
 
Understanding Forklifts - TECH EHS Solution
TECH EHS Solution
 
CHAPTER 12 - CYBER SECURITY AND FUTURE SKILLS (1) (1).pptx
AnujKumar530915
 
Digital Strategies for Manufacturing Companies
Virendra Rai, PMP
 
System and Network Administraation Chapter 3
jaramharo
 
SAP S4 Hana Brochure 3 (PTS SYSTEMS AND SOLUTIONS)
pts464036
 

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

  • 1. @crichardson The microservice architecture: what, why, when and how? Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns @crichardson chris@chrisrichardson.net adopt.microservices.io Copyright © 2023. Chris Richardson Consulting, Inc. All rights reserved
  • 4. @crichardson Agenda Developing software for today’s crazy world Architecture patterns for modern software Migrating a monolith to microservices The microservices pattern language is your guide
  • 6. @crichardson Software is eating the world Business critical application You must deliver software rapidly, frequently, reliably and sustainably You Responsible for S/W VUCA
  • 7. @crichardson Goal Your reality Measured by DORA metrics + your monolith’s technology stack is out of date https://cloud.google.com/devops/state-of-devops
  • 8. @crichardson O V I D - 1 9 https://www.ft.com/content/f9356bdc-3102-11ea-a329-0bcf87a328f2 https://www.ft.com/content/3f498e64-1aa6-11ea-97df-cc63de1d73f4 https://techcrunch.com/2019/06/18/the-rise-of-the-gig-economy-helps-london-based-insurtech-zego-to-raise-42m/ The success triangle Process: DevOps/Continuous Delivery & Deployment Organization: Network of small, loosely coupled, product teams IT must deliver software rapidly, frequently, reliably and sustainably. Measured by the DORA metrics Businesses must be nimble, agile and innovate faster S/W VUCA Architecture: ??? Supports Supports
  • 9. @crichardson Monolith or Microservice architecture? In reality: #itDepends BUT On what? ask Twitter!
  • 10. @crichardson Agenda Developing software for today’s crazy world Architecture patterns for modern software Migrating a monolith to microservices The microservices pattern language is your guide
  • 12. @crichardson Patterns: a better way to reason about architecture Reusable solution to a problem occurring in a context and its consequences
  • 13. @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
  • 14. 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
  • 15. @crichardson Data patterns Communication patterns Application architecture Cross-cutting concerns Security Deployment Maintaining data consistency External API Reliability Discovery Transactional messaging Testing Observability UI Decomposition Database architecture Querying Communication style Copyright © 2023. Chris Richardson Consulting, Inc. All rights reserved. Learn-Build-Assess Microservices http://adopt.microservices.io API gateway Client-side discovery Server-side discovery Service registry Self registration 3rd party registration Multiple Services per host Single Service per Host Service-per- Container Service-per-VM Messaging Remote Procedure Invocation Database per Service Saga Shared database Microservice Chassis Backends for frontends Event sourcing Monolithic architecture Microservice architecture Motivating Pattern Solution Pattern Solution A Solution B General Specific Serverless deployment Circuit Breaker Access Token Domain-specific Externalized configuration Consumer-driven contract test Service Component Test Exception tracking Distributed tracing Audit logging Application metrics Log aggregation Health check API Service deployment platform Server-side page fragment composition Client-side UI composition Decompose by business capability Decompose by subdomain CQRS Transaction log tailing Transactional Outbox Polling publisher API Composition Consumer-side contract test Sidecar Service mesh Aggregate Domain event Log deployments and changes Self-contained Service Service per team Service Template The Microservice Architecture Pattern Language Application patterns Infrastructure patterns Application Infrastructure patterns
  • 16. @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
  • 17. @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
  • 18. @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
  • 19. @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
  • 20. Fraud Service Customer Service Monolith Problem: how to group subdomains to form services? <<Subdomain>> Order Management <<Subdomain>> Customer Management <<Subdomain>> Fraud Management <<Subdomain>> Fraud Detection Order team Customer team Fraud Team Slices of business functionality a.k.a. business capabilities owns owns owns How to group? <<Subdomain>> Order Management <<Subdomain>> Customer Management <<Subdomain>> Fraud Management <<Subdomain>> Fraud Detection Order Service <<Subdomain>> Order Management <<Subdomain>> Customer Management <<Subdomain>> Fraud Management <<Subdomain>> Fraud Detection …OR…
  • 21. @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
  • 22. @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 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 https://microservices.io/post/microservices/2021/11/30/dark-matter-dark-energy.html
  • 23. @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 Characteristics: • Resource requirements • Regulations, e.g. SaMD/PCI • Business criticality/tier • Security, e.g. PII, … • DDD core/supporting/generic • ...
  • 24. @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 Attractive dark matter forces SystemOperation() Generates
  • 25. @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
  • 26. @crichardson Pattern: monolithic architecture *Or multiple tightly coupled (via database) services The monolithic architecture is an architectural style that structures the application as a single* executable component
  • 27. @crichardson Github Repository «Gradle Project» FtgoApplication «Gradle Subproject» main main «Gradle Subproject» orders orders.web «Gradle Subproject» customerAPI orders. domain «Gradle Subproject» customers customers. persistence orders. persistence Customer team Order team Deployment pipeline Production FTGO Application Executable JAR customers. domain customers. web customers. api Monolithic architecture (Modular): single component
  • 28. @crichardson Monolithic architecture: bene fi ts and drawbacks Repulsive forces Simple components ✅ or ❌ ∝1/ size Team autonomy ✅ or ❌ ∝1/ size Fast deployment pipeline ✅ or ❌ ∝1/ size Support multiple technology stacks ❌ Segregate by characteristic ❌ Attractive forces Simple, ef fi cient interactions ✅ Prefer ACID over BASE ✅ Minimize runtime coupling ✅ Minimize design time coupling ✅ Modularization + build technology enable the Monolithic Architecture to be used for larger applications BUT the application can ultimately outgrow its architecture when these forces cannot be resolved It can’t resolve these forces
  • 29. Pattern: microservice architecture Loosely coupled Independently deployable Implements a business capability Owned by a small team An architectural style that structures an application as a set of deployable/ executable units, a.k.a. services A service is:
  • 31. @crichardson Runtime environment Infrastructure Git repository Application code Infrastructure code … what’s a service? Application code Infrastructure code Deployment pipeline Deployable /executable Service instance Service instance Infrastructure
  • 33. @crichardson Services are loosely coupled: runtime coupling Runtime coupling between service A and B is the degree to which the availability of service A is affected by the availability of service B Order Service Customer Service POST /orders 1 PUT /customers/id Response 4 2 3 Order Service Customer Service POST /orders 1 4 2 3 Order Created event Credit Reserved Event Tight: lower availability Loose: higher availability ID partial Outcome ID Outcome https://microservices.io/patterns/decomposition/self-contained-service.html Saga
  • 34. Loosely coupled: design-time coupling The degree to which service A is forced to change in lock step with service B Caused by direct, indirect and implicit dependencies Lockstep changes: Coordination between teams Reduced productivity Changes to Customer Service affect Order Service Rarely - Loose coupling Often - Tight coupling API Order Service Customer Service reserveCredit() createOrder() Change Change Change https://microservices.io/post/microservices/2021/05/21/qcon-2021-loose-design-time-coupling.html
  • 35. Design iceberg services Implementation DB API Small, stable API Large, complex implementation Change Visible Invisible https://microservices.io/microservices/2020/02/04/jfokus-geometry-of-microservices.html
  • 36. Avoid shared database tables Order Service Customer Service Database Customer table Tight design- time/runtime coupling Order Service Customer Service Order database Order table Customer database Customer table APIs only https://microservices.io/patterns/data/database-per-service.html
  • 37. @crichardson Services implements business capabilities Services are groups of subdomains Services are NOT usually technical functions e.g. Order Data Service Fraud Service Customer Service Order Service <<Subdomain>> Order Management <<Subdomain>> Customer Management <<Subdomain>> Fraud Management <<Subdomain>> Fraud Detection
  • 38. @crichardson Dark matter A service is owned by a small team… Order team Order Service <<Subdomain>> Order Management Customer team Customer Service <<Subdomain>> Customer Management Order team Order Service <<Subdomain>> Order Management Customer team <<Subdomain>> Customer Management Ensures team autonomy and resolves other dark energy forces Teams can still be mostly autonomous Dark matter https://microservices.io/patterns/decomposition/service-per-team.html https://microservices.io/post/antipatterns/2019/05/21/antipattern-more-the-merrier.html
  • 39. @crichardson … Owned by a small team Fraud Team Fraud Service <<Subdomain>> Fraud Management Fraud Detection Service <<Subdomain>> Fraud Detection Additional service solves tangible problem, e.g. resolves a dark energy force Java Python
  • 40. @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
  • 41. @crichardson Use the microservice architecture when: Large application and/or development organization Need multiple technology stacks Segregating subdomains by their characteristics is bene fi cial Resource requirements => better scalability Business critically => better availability Regulatory requirements => faster development …
  • 42. @crichardson Agenda Developing software for today’s crazy world Architecture patterns for modern software Migrating a monolith to microservices The microservices pattern language is your guide
  • 43. @crichardson Six principles for migrating a monolith to Microservices 1. Make the most of your monolith 2. Adopt microservices for the right reasons 3. Migrate incrementally 4. Begin with the end in mind 5. Migrate high-value modules fi rst 6. Success is improved velocity and reliability https://microservices.io/post/refactoring/2020/07/28/six-principles-for-refactoring-to-microservices.html
  • 44. @crichardson Principle #1: Make the most of the monolithic architecture If software delivery is slow Optimize development process Improve deployment pipeline = more automation Improve team autonomy Modularize the monolith to enable independent development Eliminate hand-offs and create cross functional teams If technology stack is obsolete modernize to a new monolith …
  • 45. @crichardson If and only if that is insuf fi cient* then consider migrating to microservices *Large, complex applications developed by a (usually) large team that need to be delivered rapidly, frequently, and reliably
  • 46. @crichardson Principle #2: Adopt microservices for the right reasons https://microservices.io/post/microservices/2021/11/30/dark-matter-dark-energy.html Service Service «Subdomain» A «Aggregate» X «Subdomain» B «Aggregate» Y Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Segregate by characteristics Repulsive dark energy forces Characteristics: • Resource requirements • Regulations, e.g. SaMD/PCI • Business criticality/tier • Security, e.g. PII, … • DDD core/supporting/generic • ...
  • 47. @crichardson Principle #3: Begin with the end in mind - de fi ne a target architecture Target architecture Assemblage process http://microservices-assemblage.io/
  • 48. @crichardson Principle #4: Migrate incrementally Monolith Time Monolith Service Monolith Service Service Monolith Service Service Service Service …. Monolith Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service Service …. Strangler application The strangler application grows larger over time The monolith shrinks over time Service Service Service Service Service Service Service Service New features https://microservices.io/patterns/refactoring/strangler-application.html
  • 49. @crichardson Principle #5: Migrate high- value modules fi rst Bene fi t of extraction Ease of extraction High High Low Low Module B Module A Module C Module D Module E
  • 50. @crichardson Principle #6: Measuring success Success != Number of Microservices Success = Improved DORA metrics: Reduced lead time Increased deployment frequency Reduced changed failure rate Improvements in other -ilities … Anti-pattern: Microservices as the goal https://microservices.io/post/antipatterns/2019/01/14/antipattern-microservices-are-the-goal.html
  • 51. @crichardson Agenda Developing software for today’s crazy world Architecture patterns for modern software Migrating a monolith to microservices The microservices pattern language is your guide
  • 52. @crichardson Deciding to use the microservice architecture is just the beginning Deployment De fi ne services Observe UI Communication Test Cross cutting concerns “Data”
  • 53. @crichardson Data patterns Communication patterns Application architecture Cross-cutting concerns Security Deployment Maintaining data consistency External API Reliability Discovery Transactional messaging Testing Observability UI Decomposition Database architecture Querying Communication style Copyright © 2023. Chris Richardson Consulting, Inc. All rights reserved. Learn-Build-Assess Microservices http://adopt.microservices.io API gateway Client-side discovery Server-side discovery Service registry Self registration 3rd party registration Multiple Services per host Single Service per Host Service-per- Container Service-per-VM Messaging Remote Procedure Invocation Database per Service Saga Shared database Microservice Chassis Backends for frontends Event sourcing Monolithic architecture Microservice architecture Motivating Pattern Solution Pattern Solution A Solution B General Specific Serverless deployment Circuit Breaker Access Token Domain-specific Externalized configuration Consumer-driven contract test Service Component Test Exception tracking Distributed tracing Audit logging Application metrics Log aggregation Health check API Service deployment platform Server-side page fragment composition Client-side UI composition Decompose by business capability Decompose by subdomain CQRS Transaction log tailing Transactional Outbox Polling publisher API Composition Consumer-side contract test Sidecar Service mesh Aggregate Domain event Log deployments and changes Self-contained Service Service per team Service Template The Microservice Architecture Pattern Language Application patterns Infrastructure patterns Application Infrastructure patterns Application Infrastructure Application and Infrastructure
  • 54. Database architecture Shared database “Simple”, e.g. ACID But creates tight design-time coupling Best avoided Database per service Reduces design-time coupling But potentially more complex, e.g. no ACID transactions between services https://microservices.io/patterns/data/shared-database.html https://microservices.io/patterns/data/database-per-service.html Service Shared database Service Database (Schema) Service Database per service Service Database (Schema) Database (Schema)
  • 55. @crichardson Database per service => eventually consistent service collaboration patterns API Composition Provider Service Service query() Composer Provider Service Provider Service CQRS Provider Service Service query() View Provider Service Provider Service Event Event Event Service Service Service Transaction Compensating transaction Transaction Compensating transaction Transaction Compensating transaction command() Saga Service Service command() Replica Source Event Command-side replica Commands Queries https://microservices.io/patterns/index.html#data-management
  • 56. Communication patterns Remote procedure invocation e.g. REST Simple and familiar But results in tight runtime coupling Use carefully Asynchronous messaging e.g. events Loose runtime coupling More complex Preferred https://microservices.io/patterns/index.html#style Service Service Request Response Remote Procedure Invocation Service Service Messaging Message channel
  • 57. Deployment patterns Numerous options with different trade-offs Use serverless if you can Otherwise, use containers Virtual Machine Service Service per VM Container Service Service per Container Serverless infrastructure Service Serverless Serverless framework
  • 58. Summary Monolith or microservices? #itDepends The microservices pattern language is your guide Dark energy and dark matter forces drive the design Remember the principles for refactoring to microservices Incrementally refactor a monolith to microservices adopt.microservices.io @crichardson