Using patterns and pattern languages to make better architectural decisions

@crichardson A pattern language for microservices Chris Richardson Microservice architecture consultant and trainer 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 © 2022. Chris Richardson Consulting, Inc. All rights reserved

@crichardson Presentation goal Why patterns and pattern languages? A pattern language for microservices

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

@crichardson Discounts 35% discount au35ric $100 discount coupon SFKXWOZQ until 3/17 http://adopt.microservices.io

@crichardson Agenda Why a pattern language for microservices? Core patterns: Monolith vs. Microservices Distributed data patterns in a microservice architecture

@crichardson “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 Development • Maintainability • Testability • Deployability • … Architect Nonfunctional requirements Runtime • Scalability • Performance • Availability • … Satisfies Defines Architecture

@crichardson Monolith or Microservices? In reality: it depends BUT On what? ask Twitter!

@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 Benefits Drawbacks Issues Alternative Pattern Patterns that address issues Context Problem Solution aka the situation (conflicting) issues/ requirements/etc to address Force Consequences

Pattern language A collection of related patterns that identify and solve problems in a particular domain http://en.wikipedia.org/wiki/A_Pattern_Language Motivating Pattern Solution Pattern Solution Pattern A Solution Pattern B Generic Pattern Specific Pattern Has issue Solves issue Alternative solutions Refines Valuable

@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 Benefits Drawbacks Issues Context Problem: what is the application’s architecture? Solution Forces Benefits Drawbacks Issues Solution

@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 = context Process: Lean + DevOps/Continuous Delivery & Deployment Organization: Network of small, loosely coupled, product teams IT must deliver software rapidly, frequently, reliably and sustainably: Businesses must be nimble, agile and innovate faster S/W VUCA • Deployment frequency: >= once per developer/day • < 15 minute lead time • … Architecture Enables Enables Enables

Required architectural quality attributes (a.k.a. -ilities) “Complete their work without communicating and coordinating with people outside their team” “Make large-scale changes to the design of their system without depending on other teams to make changes in their systems or creating significant work for other teams” “We can do most of our testing without requiring an integrated environment.” “We can and do deploy or release our application independently of other applications/services it depends on.” Loosely coupled (Conway’s law) Modular Testable Deployable API encapsulates design decisions

@crichardson Architecting for sustainable software development Evolvability/Modularity Must be able to incrementally upgrade the technology stack API encapsulates the technology stack

Architecture is multi- dimensional: 4+1 view model Logical View Process View Deployment View Implementation View Scenarios https://en.wikipedia.org/wiki/4%2B1_architectural_view_model View = (elements, relations) Scenario: shows how a view’s elements collaborate

4+1 Logical view: “programming” Logical View Process View Deployment View Implementation View Scenarios Elements: classes, packages, subdomains Relations: inheritance, associations, … About Subdomains • Business capability/function/etc • Team-sized «Subdomain» Customer management firstName lastName «aggregate» Customer «Subdomain» Order management deliveryTime … «aggregate» Order Quantity … «aggregate» OrderLineItem «Subdomain» Restaurant management name … «aggregate» Restaurant name … «aggregate» MenuItem Customer management team Owns Order management team Owns Restaurant management team Owns

4+1 Implementation view: “build artifacts” Logical View Process View Deployment View Implementation View Scenarios Elements: modules and components Relations: dependencies

@crichardson Choice of architectural styles Application Service ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ Service Service Application ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ Monolithic architecture: One component Microservice architecture: Many components Problem: how to partition subdomains into components?

@crichardson Grouping subdomains into components: together or separate? ≪subdomain≫ Customer ≪aggregate≫ Customer ≪subdomain≫ Order ≪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://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.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 Cost eﬀective scaling Segregate regulated software Segregate highly available components

@crichardson Dark matter: attractive forces subdomains in same service https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html System Operation() Service Service «Subdomain» A «Aggregate» X «Subdomain» B «Aggregate» Y Simple interactions Prefer ACID over BASE Minimize runtime coupling Eﬃcient inter-service communication Minimize design time coupling

@crichardson The role of the architect is to balance conflicting forces Minimize attraction Service Subdomain Subdomain Minimize repulsion Service Subdomain Subdomain Minimize repulsion Conflicting goals

@crichardson Monolith vs. Microservices Application Service ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ Service Service Application ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ Monolithic architecture: One component Microservice architecture: Many components Resolves Potentially neglects Potentially neglects Resolves

@crichardson Solution: 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: benefits and drawbacks Repulsive forces Simple components ✅ or ❌ ∝1/ size Team autonomy ✅ or ❌ ∝1/ size Fast deployment pipeline ✅ or ❌ ∝1/ size Support multiple technology stacks ❌ Cost effective scaling ✅ if role-based deployments Segregate regulated software ❌ Segregate highly available components ❌ Attractive forces Simple interactions ✅ Prefer ACID over BASE ✅ Minimize runtime coupling ✅ Efficient inter-service communication ✅ Minimize design time coupling ✅ Depends on size It can’t resolve these forces

@crichardson Issues How to enable many developers to frequently commit their changes? How to improve productivity by enabling developers to work on part of the application? How to enable teams to work independently? How to accelerate deployment pipeline? Merge Queue Modular Monolith Parallelization Simple components ✅ or ❌ ∝1/ size Team autonomy ✅ or ❌ ∝1/ size Fast deployment pipeline ✅ or ❌ ∝1/ size

Solution: microservice architecture Highly maintainable and testable Minimal lead time (time from commit to deploy) Loosely coupled Independently deployable Implements a business capability Owned/developed/tested/ deployed 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 Microservice architecture: Many components Production Github Repository Github Repository «Gradle project» orders orders.web orders. domain «Gradle project» customers customers. persistence orders. persistence Customer team Order team Deployment pipeline «Executable JAR» Order Service customers. domain customers. web customers. main orders.main «Executable JAR» Customer Service Deployment pipeline «Service Instance» Order Service «Service Instance» Customer Service Inter-service Communication

@crichardson Microservice architecture: benefits and drawbacks Repulsive forces Simple components ✅ Team autonomy ✅ Fast deployment pipeline ✅ Support multiple technology stacks ✅ Cost effective scaling ✅ Segregate regulated software ✅ Segregate highly available components ✅ Attractive forces Simple interactions ❌ Prefer ACID over BASE ❌ Minimize runtime coupling ❌ Efficient inter-service communication ❌ Minimize design time coupling ❌ Key issue Must group subdomains to: • Maximize benefits • Minimize drawbacks Potential benefits Potential drawbacks

@crichardson Many other issues: how to …? Deployment Define services Observe UI Communication Test Cross cutting concerns “Data”

@crichardson Context: you’ve applied the microservice architecture Application Customer Service ≪entity≫ Customer Order Service ≪entity≫ Order createCustomer() createOrder() findOrder() findOrderHistory() System operations Transactional • Persistent • Owned by service Read/ Write

@crichardson Database Server Database Schema Database Server Database Schema Problem: what’s the database schema architecture? Monolith Database Schema Order Service Customer Service Restaurant Service Database Schema ???? 1-1

@crichardson Pattern: Shared database schema Order Service Customer Service Order table Customer table createOrder() ACID Transaction https://microservices.io/patterns/data/shared-database.html

@crichardson Benefits and drawbacks: shared schema Shared schema Dark energy repulsive forces Simple components ✅ Team autonomy ❌ Support multiple technology stacks ❌ Cost effective scaling ❌ Segregate highly available components ❌ Dark matter attractive forces Simple interactions ✅ Prefer ACID over BASE ✅ Minimize runtime coupling ❌ Efficient inter-service communication ✅ Minimize design time coupling ❌ Simple ACID BUT tightly coupled, …

@crichardson Pattern: Private database schema Orders Service Customer Service Order table Customer table API createOrder() Transaction ??? https://microservices.io/patterns/data/database-per-service.html

@crichardson Context: Applied private database schema Problem: How to implement transactions? https://en.wikipedia.org/wiki/Two-phase_commit_protocol Pattern: 2PC Pattern: Saga https://microservices.io/patterns/data/saga.html

@crichardson Benefits and drawbacks Private schema 2PC Saga Dark energy repulsive forces Simple components ✅ ? Team autonomy ❌ ✅ Support multiple technology stacks ❌ ✅ Cost effective scaling ❌ ✅ Segregate highly available components ❌ ✅ Dark matter attractive forces Simple interactions ✅ ? Prefer ACID over BASE ✅ ❌ Minimize runtime coupling ❌ ✅ Efficient inter-service communication ? ? Minimize design time coupling ✅ ✅ 😀 😀 😀 😢

@crichardson Summary: Patterns and pattern languages are a great way to … Think about technology Discuss technology Choose technology

@crichardson Summary: The Microservices pattern language is a great way to … Think about architecture Discuss architecture Choose an architecture: monolith or microservices

@crichardson Summary https://www.nasa.gov/feature/goddard/2020/new-hubble-data-explains-missing-dark-matter https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html Dark energy and dark matter are excellent metaphors for the forces that determine service boundaries

@crichardson @crichardson chris@chrisrichardson.net http://adopt.microservices.io Questions? au35ric SFKXWOZQ

Using patterns and pattern languages to make better architectural decisions

More Related Content

What's hot

Similar to Using patterns and pattern languages to make better architectural decisions

More from Chris Richardson

Recently uploaded

Using patterns and pattern languages to make better architectural decisions