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.

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 chris@chrisrichardson.net http://adopt.microservices.io Copyright © 2024. Chris Richardson Consulting, Inc. All rights reserved
2. @crichardson Presentation goal Describe the past, present and future of the 10 year pattern language
3. @crichardson About Chris http://adopt.microservices.io
4. @crichardson About Chris https://chrisrichardson.net/
5. @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
6. @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
7. @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
8. @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
9. @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
10. 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
11. @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
12. @crichardson About the Microservice Architecture pattern language Decide Apply Help software architects and developers & Application architecture Monolithic architecture Microservice architecture
13. @crichardson Back in 2014…
14. @crichardson … haphazardly evolved over time…
15. @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
16. @crichardson Published in 2018 Written 2016-2018 https://microservices.io/book
17. @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
18. @crichardson An early de fi nition https://web.archive.org/web/20140907090420/http://microservices.io/patterns/microservices.html “Formulaic phrase”: spoken without conscious thought ?
19. @crichardson Rediscovering the discipline of software architecture SEI Architecture Technology User Network
20. 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)
21. @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)
22. @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)
23. @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
24. @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
25. @crichardson Loose coupling - re fi ned Coupling Design-time coupling Runtime coupling Team autonomy & productivity Application availability → → Primarily
26. @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
27. @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
28. @crichardson Two key questions: Monolith or microservices? If microservices, what are the service boundaries?
29. @crichardson Components as groups of subdomains
30. @crichardson Component/Service architecture = partitioning of subdomains
31. @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
32. @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
33. @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
34. @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
35. @crichardson Designing an architecture = making trade-offs Con fl icting forces Therefore Some services/ operations will have an optimal design Others will be suboptimal but good enough Subdomain A «Aggregate» X Subdomain B «Aggregate» Y Service A Service B Attraction Simple, efficient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Segregate by characteristics Repulsion Dark energy Dark matter Metaphor for Metaphor for Fine-grained services Monolith
36. @crichardson 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
37. @crichardson Journey thru decomposition patterns: too simplistic Microservice architecture Decomposition Decompose by business capability Decompose by subdomain Self-contained Service Service per team …. …. X
38. @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
39. @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/
40. @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
41. @crichardson Improvement: Naming solution participants - roles Providers
42. @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
43. @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
44. @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
45. 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
46. @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!
47. @crichardson @crichardson chris@chrisrichardson.net http://adopt.microservices.io Questions?