@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

@crichardson Presentation goal Describe the past, present and future of the 10 year pattern language

@crichardson About Chris http://adopt.microservices.io

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

@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

@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

@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

@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

@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

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

@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

@crichardson About the Microservice Architecture pattern language Decide Apply Help software architects and developers & Application architecture Monolithic architecture Microservice architecture

@crichardson Back in 2014…

@crichardson … haphazardly evolved over time…

@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

@crichardson Published in 2018 Written 2016-2018 https://microservices.io/book

@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

@crichardson An early de fi nition https://web.archive.org/web/20140907090420/http://microservices.io/patterns/microservices.html “Formulaic phrase”: spoken without conscious thought ?

@crichardson Rediscovering the discipline of software architecture SEI Architecture Technology User Network

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)

@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)

@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)

@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

@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

@crichardson Loose coupling - re fi ned Coupling Design-time coupling Runtime coupling Team autonomy & productivity Application availability → → Primarily

@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

@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

@crichardson Two key questions: Monolith or microservices? If microservices, what are the service boundaries?

@crichardson Components as groups of subdomains

@crichardson Component/Service architecture = partitioning of subdomains

@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

@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

@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

@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

@crichardson Designing an architecture = making trade-offs Con fl icting forces Therefore Some services/ operations will have an optimal design Others will be suboptimal but good enough Subdomain A «Aggregate» X Subdomain B «Aggregate» Y Service A Service B Attraction Simple, efficient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Segregate by characteristics Repulsion Dark energy Dark matter Metaphor for Metaphor for Fine-grained services Monolith

@crichardson 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

@crichardson Journey thru decomposition patterns: too simplistic Microservice architecture Decomposition Decompose by business capability Decompose by subdomain Self-contained Service Service per team …. …. X

@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

@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/

@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

@crichardson Improvement: Naming solution participants - roles Providers

@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

@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

@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

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

@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!

@crichardson @crichardson [email protected] http://adopt.microservices.io Questions?