Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥

PLoP 2024: The evolution of the microservice ar...

PLoP 2024: The evolution of the microservice architecture pattern language

The microservice architecture pattern language is a collection of patterns for designing a microservice architecture. The pattern language came into existence on March 18th, 2014 with a Git commit to microservices.io that contained the first two patterns: monolithic architecture and microservice architecture. Since then it has grown to 40+ patterns. I gave a presentation about the pattern language at PLoP 2017. And, my best selling book, Microservices Patterns, was published in 2018.

In this presentation, I describe how the pattern language has evolved over the years. You will learn how dark energy and dark matter have emerged as useful metaphors for the forces that various patterns must resolve. I describe how patterns have proved to be insufficient for defining service boundaries and how they are simply an element of a rigorous design process. You will learn about upcoming improvements to the pattern language.

Chris Richardson

October 27, 2024
Tweet

More Decks by Chris Richardson

Other Decks in Programming

Transcript

  1. @crichardson The evolution of the Microservice Architecture pattern language Chris

    Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns @crichardson [email protected] http://adopt.microservices.io Copyright © 2024. Chris Richardson Consulting, Inc. All rights reserved
  2. @crichardson Chris ❤ Patterns Excited by the Gang of Four

    patterns book Vague memories of organizing a patterns discussion group in the 1990s Planned to go to PLoP 2001 (A Pattern Language for J2EE Web Component Development1) but …. Patterns/Pattern-style thinking (bene fi ts/drawbacks/issues) are the antidote to the suck/rock dichotomy thinking that pervades the software community
  3. @crichardson Agenda Introduction to the microservice architecture pattern language Evolving

    the de fi nition of the microservice architecture The dark energy and dark matter forces Looking towards the future
  4. @crichardson About software architecture “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
  5. @crichardson Goal of architecture satis fi es Application requirements Functional

    requirements (Features) Non-functional requirements Runtime behavior Ease of development Users Developers inhabit the architecture Constant change Application architecture
  6. @crichardson About architectural styles "… An architectural style determines the

    vocabulary of components (i.e. elements) and connectors (ie. relations) that can be used in instances of that style, together with a set of constraints on how they can be combined….. ” David Garlan and Mary Shaw, An Introduction to Software Architecture Classical Byzantine Art Deco
  7. About the Microservice Architecture Name popularized in March 2014 by

    James Lewis/Martin Fowler blog post But it’s much, much older than that, e.g. Amazon 2002 Teams work independently on their services Architectural style consisting of two or more services Primary goal: enable fast fl ow
  8. @crichardson Fast fl ow for business succe$$: Continuous stream of

    small changes, many times a day Development Production Continuous feedback and learning Users Wiring the winning organization, Gene Kim et al
  9. @crichardson About the Microservice Architecture pattern language Decide Apply Help

    software architects and developers & Application architecture Monolithic architecture Microservice architecture
  10. @crichardson 2018: Anti-patterns of microservices adoption Magic pixie dust Microservices

    as the goal Scattershot adoption Trying to fl y before you can walk Focussing on technology The more the merrier Red fl ag law
  11. @crichardson Agenda Introduction to the microservice architecture pattern language Evolving

    the de fi nition of the microservice architecture The dark energy and dark matter forces Looking towards the future
  12. The microservice architecture is an architectural style that structures an

    application as a set of two or more loosely coupled, independently deployable components (a.k.a services)
  13. @crichardson It’s an architectural style The microservice architecture is an

    architectural style that structures an application as a set of two or more loosely coupled, independently deployable components (a.k.a services)
  14. @crichardson … that organizes components… The microservice architecture is an

    architectural style that structures an application as a set of two or more loosely coupled, independently deployable components (a.k.a services)
  15. @crichardson Architecture is multi-dimensional E.g. Structural, electrical, plumbing, mechanical 㱺

    Described by multiple blueprints (aka. Views) View = (elements, relations, properties) https://microservices.io/post/architecture/2024/04/14/architecture-is-multi-dimensional.html
  16. @crichardson Component architecture = one or more components Component (Application)

    1 component = Monolithic architecture Component/Service X Component/Service Y Component/Service Z 2+ components = Microservice architecture OR
  17. @crichardson Loose coupling - re fi ned Coupling Design-time coupling

    Runtime coupling Team autonomy & productivity Application availability → → Primarily
  18. @crichardson Independently deployable = test in isolation and then release*

    https://microservices.io/post/architecture/2022/05/04/microservice-architecture- essentials-deployability.html * Vs. change a lightbulb above a ✈ seat => test fl ight
  19. @crichardson Agenda Introduction to the microservice architecture pattern language Evolving

    the de fi nition of the microservice architecture The dark energy and dark matter forces Looking towards the future
  20. @crichardson Grouping subdomains into components: together or separate? ≪subdomain≫ Customer

    management ≪aggregate≫ Customer ≪subdomain≫ Order management ≪aggregate≫ Order Attraction Repulsion Generated by system operations 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 interactions Prefer ACID or BASE Minimize runtime coupling … https://microservices.io/post/architecture/2023/03/26/dark-energy-dark-matter-force-descriptions.html
  21. @crichardson Dark energy and dark matter forces https://microservices.io/post/architecture/2023/03/26/dark-energy-dark-matter-force-descriptions.html 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
  22. @crichardson Microservice architecture Monolithic architecture Consequences Context Problem: what is

    the application’s architecture? Solution Forces Consequences 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
  23. @crichardson Service collaboration pattern forces Subdomain A «Aggregate» X Subdomain

    B «Aggregate» Y Service A Service B Attraction Simple interactions Efficient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Segregate by characteristics Repulsion Dark energy Dark matter Metaphor for Metaphor for
  24. @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
  25. @crichardson Context Your context determines relevance of dark forces Development

    organization size Team autonomy Application size Rate of Git pushes Fast deployment pipeline Number of teams Forces
  26. @crichardson Journey thru decomposition patterns: too simplistic Microservice architecture Decomposition

    Decompose by business capability Decompose by subdomain Self-contained Service Service per team …. …. X
  27. @crichardson Assemblage: design process Incrementally de fi nes One operation

    at a time https://microservices.io/post/architecture/2023/02/09/assemblage-architecture-de fi nition-process.html
  28. @crichardson Key heuristic: Service exists to solve a problem Service

    Solves Creates Architecture = Past design decisions https://premium.microservices.io/microservices-rules-5-deliberative-decision-making/
  29. @crichardson Agenda Introduction to the microservice architecture pattern language Evolving

    the de fi nition of the microservice architecture The dark energy and dark matter forces Looking towards the future
  30. @crichardson Remove database architecture patterns 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 © 2024. 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 Database architecture Database per Service Shared database X X False Choice
  31. @crichardson Service discovery: mostly handled by infrastructure 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 © 2024. 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 Discovery Client-side discovery Server-side discovery Service registry Self registration 3rd party registration
  32. @crichardson De fi ne relationship between patterns and Team topologies

    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 © 2024. 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 Stream aligned team, e.g. Order Management Develop Test Deploy Stream aligned team, e.g. Order Management Develop Test Deploy
  33. Alternative pattern: Modular monolith Understand The problems that the Microservice

    Architecture solves How it solves those problem Apply ideas to the monolithic architecture: Modularity - simplicity and team autonomy Minimize build-time coupling to accelerate builds Monolithic architecture Microservice architecture
  34. @crichardson Summary Microservice architecture pattern language is ten years old

    and still relevant Leverage existing bodies of work, e.g. software architecture discipline Evolve patterns when: You understand more about a domain The domain evolves Watch your language, words matter!