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

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

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

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

5. @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

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!

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

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

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…

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 Eﬃcient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Segregate by characteristics Repulsion Dark energy Dark matter Metaphor for Metaphor for https://microservices.io/post/microservices/2021/11/30/dark-matter-dark-energy.html

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

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:

30. @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

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

32. @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

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 …

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

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

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

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

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

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

Plus De Contenu Connexe

Similaire à The microservice architecture: what, why, when and how? (20)

Plus par Chris Richardson (20)

Plus récents (20)