Microservices rules: what good looks like

Slide 1

Slide 1 text

@crichardson Microservices rules: what good looks like 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

Slide 2

Slide 2 text

@crichardson “Our application is ‘****’, it's so complex and so dif fi cult to change” Architect of ancient legacy application Developer of a young microservices application

Slide 3

Slide 3 text

@crichardson Presentation goal 11 rules that prevent an organization from making a mess of its microservice architecture

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

@crichardson Agenda Development rules A really brief overview of software architecture Rule: use a rational design process Architecture rules Rule: Track and improve software metrics and KPIs

Slide 6

Slide 6 text

@crichardson O VID -19 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 Businesses must be nimble, agile and innovate faster S/W VUCA Architecture: ??? Enables Enables

Slide 7

Slide 7 text

What is DevOps? Set of principles and practices where developers, testers (dev) and IT operations (ops) collaborate and communicate to deliver software rapidly, frequently, and reliably http://itrevolution.com/devops-handbook Three ways Flow Feedback Learning

Slide 8

Slide 8 text

@crichardson Rule #1: Practice continuous delivery/ deployment https://continuousdelivery.com/

Slide 9

Slide 9 text

@crichardson About continuous delivery/ deployment The ability to get changes into production safely and quickly in a sustainable way. Code (Git) repository is the source of truth Software is always releasable Developers commit frequently - e.g. daily - to trunk Highly automated

Slide 10

Slide 10 text

@crichardson Rule #2: Implement a fast deployment pipeline Production Fast, automated deployment pipeline Developer laptop Application repository 15 minutes

Slide 11

Slide 11 text

High performance organization: team of teams Small - 5-9 people - promotes productivity and trust Long-lived - enables trust and high performance Cross-functional: requirements -> deployed code Typically owns suitably sized software “component” Promotes long-term sustainable development Prevents cognitive overload Component: Business capability Platform that accelerate delivery of components https://teamtopologies.com/key-concepts

Slide 12

Slide 12 text

@crichardson Teams primarily work independently - collaborate to (re)de fi ne APIs

Slide 13

Slide 13 text

@crichardson Rule #3: Have small, cross-functional, loosely-coupled teams

Slide 14

Slide 14 text

@crichardson “Developer experience (DevEx) encompasses how developers feel about, think about, and value their work.” https://queue.acm.org/detail.cfm?id=3595878

Slide 15

Slide 15 text

@crichardson DevEx framework DevEx Work environment than minimizes interruptions, meaningful work, … Minimize - simplify environment, automate, good documentation, … Fast feedback from colleagues, tools, deployment pipeline, production, users, … Feedback Flow Cognitive load https://queue.acm.org/detail.cfm?id=3595878 Great

Slide 16

Slide 16 text

@crichardson Rule #4: Provide a great DevEx

Slide 17

Slide 17 text

@crichardson https://www.dedionboutonclub.co.uk/imperial_institute_page1.html Anti-pattern: Red fl ag law Adopting microservices without DevOps, Team Topologies, great DevEx…

Slide 18

Slide 18 text

@crichardson Agenda Development rules A really brief overview of software architecture Rule: use a rational design process Architecture rules Rule: Track and improve software metrics and KPIs

Slide 19

Slide 19 text

@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 Development • Maintainability • Testability • Deployability • … Nonfunctional requirements Runtime • Scalability • Performance • Availability • … Satis fi es Architecture Focus

Slide 20

Slide 20 text

@crichardson How to organize subdomains into components to meet these requirements? External behavior Business logic/ capability

Slide 21

Slide 21 text

@crichardson Monolithic architecture: one component Production Fast, automated deployment pipeline Application repository Developer laptop App

Slide 22

Slide 22 text

@crichardson Microservice architecture: two or more components Production Deployment pipeline Service Repo Deployment pipeline Service Repo Deployment pipeline Service Repo Independently deployable Loosely coupled Svc Svc Svc

Slide 23

Slide 23 text

@crichardson Which best fi ts your application and organization? #itDepends

Slide 24

Slide 24 text

@crichardson Agenda Development rules A really brief overview of software architecture Rule: use a rational design process Architecture rules Rule: Track and improve software metrics and KPIs

Slide 25

Slide 25 text

@crichardson Architecture = series of design decisions https://premium.microservices.io/a-service-should-exist-to-solve-a-problem/

Slide 26

Slide 26 text

Rational vs. Irrational decision making Irrational @FamousDev says X is good/bad X looks like a cool, new thing to try X would look good on my resume I’ve used X in my past 5 jobs Magical thinking: we can neglect architecture …   Rational 1. Understand your context 2. Understand your problem 3. De fi ne the evaluation criteria 4. Identify candidate solutions 5. Evaluate solutions wrt. criteria 6. Pick the best solution 7. Document using an ADR https://microservices.io/post/architecture/2023/03/13/better-decision-making-with-patterns.html Requires knowledge Only you know this

Slide 27

Slide 27 text

@crichardson Spectrum of design decisions What to build vs. what to buy? Monolith or microservice architecture? If microservices => what’s the service architecture: APIs, responsibilities, and collaboration? How to deploy services? Which message broker to use? … Big Small

Slide 28

Slide 28 text

Monolith vs microservices: which best fi ts your application/organization? Enables

Slide 29

Slide 29 text

@crichardson Architectural requirement: loose coupling Order Management Customer Management Develops Develops Unaffected by changes to the other Conway’s law Loosely coupled = work independently Loosely coupled Degree of design-time coupling = probability of lockstep changes

Slide 30

Slide 30 text

@crichardson Loose coupling is a fundamental principle of software design Ignore at your peril! of classes, packages, modules, services, applications, … V

Slide 31

Slide 31 text

@crichardson Architectural requirements: testability and deployability Production Automated deployment pipeline >= 1 commit / developer / day Must be fast running Must be reliable Must be testable using automated tests deployment Must be locally testable commit

Slide 32

Slide 32 text

@crichardson Architecting for DevEx https://queue.acm.org/detail.cfm?id=3595878 Loose coupling Testability Deployability Observability Simplicity

Slide 33

Slide 33 text

@crichardson Architectural requirements distilled into dark energy and dark matter 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 … SystemOperation() Generates Forces that act on subdomains and determine grouping into services

Slide 34

Slide 34 text

@crichardson Dark energy forces: reasons to use microservices https://microservices.io/post/architecture/2023/03/26/dark-energy-dark-matter-force-descriptions.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 • ...

Slide 35

Slide 35 text

@crichardson But your context determines relevance of dark energy forces to you Force: reason to use microservices What determine relevance to your application Team autonomy ∝Number of teams Fast deployment pipeline Build time ∝ size/complexity of app Build frequency ∝ rate of Git pushes Multiple technology stacks Need multiple technologies? Segregate by characteristics Business criticality Have high availability subdomains? Regulations Regulated subdomains? …

Slide 36

Slide 36 text

@crichardson IF you have this DevEx… Large monolith • High cognitive load • Less autonomy • More meetings • Slow feedback Single classpath, Large code base, Slow deployment pipeline, … Simple (e.g. ACID txns) development BUT You

Slide 37

Slide 37 text

@crichardson …THEN adopt microservices to have this DevEx Service Small part of a large application Service … Service … Service … collaborators A P I • Less cognitive load • More autonomy incl. technical • Less meetings • Faster feedback You A P I A P I A P I Service … Service … clients

Slide 38

Slide 38 text

How many services? MICROservices != little services Excessively fi ne-grained, overly complex architectures are far too common A service should exist to solve a tangible problem https://microservices.io/post/antipatterns/2019/05/21/antipattern-more-the-merrier.html https://premium.microservices.io/a-service-should-exist-to-solve-a-problem/

Slide 39

Slide 39 text

@crichardson Fine-grained architecture: risk of poor DevEx Right-sized Service A P I Fine- grained Service API Good ✅ Bad ❌ Focus on collaboration logic Focus on domain logic

Slide 40

Slide 40 text

@crichardson Dark matter forces: reasons NOT to distribute subdomains 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 Simple interactions Eﬃcient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Attractive dark matter forces SystemOperation() Generates

Slide 41

Slide 41 text

@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, 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 Fine-grained services Monolith

Slide 42

Slide 42 text

@crichardson Assemblage: an architecture de fi nition process that’s powered by dark energy and dark matter* https://microservices.io/post/architecture/2023/02/09/assemblage-architecture-de fi nition-process.html Subdomain A «Aggregate» X Subdomain B «Aggregate» Y Service A Service B Dark energy Dark matter * metaphor overload

Slide 43

Slide 43 text

@crichardson Agenda Development rules A really brief overview of software architecture Rule: use a rational design process Architecture rules Rule: Track and improve software metrics and KPIs

Slide 44

Slide 44 text

@crichardson Architecture rules #6 Design loosely coupled services #7 Design independently deployable services #8 Design testable services #9 Develop observable services #10 Incrementally migrate from a monolith to microservices De fi ning characteristics of microservices

Slide 45

Slide 45 text

Rule #6: Design loosely (design-time*) coupled services * vs runtime and build-time coupling https://microservices.io/post/architecture/2023/03/28/microservice-architecture-essentials-loose-coupling.html Customer Service Customer Subdomain Order Service Order Subdomain API Stable Infrequent lock step changes

Slide 46

Slide 46 text

The problem with tight design- time coupling Changing services in lock step reduces productivity: API changes/evolution Complexity of non-atomic changes of independently deployable services Coordination between teams Worst case: distributed monolith! Therefore: Tightly coupled subdomains should be packaged together Order Service Customer Subdomain Order Subdomain Package together

Slide 47

Slide 47 text

Design iceberg services Implementation DB API Small, stable API Large, complex implementation Change https://microservices.io/post/architecture/2023/03/01/geometry-of-microservices.html

Slide 48

Slide 48 text

@crichardson Rule #7: design independently deployable services https://microservices.io/post/architecture/2022/05/04/microservice-architecture-essentials-deployability.html Production Order Service Order Service Deployment pipeline Test in isolation Test Service Test Double Service Sole criteria for release Includes contract- testing to enforce API interoperability Deploy automatically

Slide 49

Slide 49 text

@crichardson Why independently deployable services? De fi ning characteristic of the microservice architecture Testing a service in isolation Simpler testing set up using test doubles Fast Reliable Testing services together = distributed monolith = downsides of both with few of the bene fi ts By de fi nition: the output of a deployment pipeline is deployable

Slide 50

Slide 50 text

@crichardson Rule #8: Design testable services Automated - tests must be automated Fast - tests must execute quickly to provide fast feedback Reliable - tests must not be fl aky: failing test = real problem Locally executable - tests must run on a developer's laptop to provide fast feedback. Isolated - tests must use test doubles for the service's dependencies

Slide 51

Slide 51 text

@crichardson The testing pyramid and microservices Unit Integration Includes consumer-driven contract tests Component End to End Classes within service A services adapters An entire service Multiple services or application Services are independently deployable

Slide 52

Slide 52 text

@crichardson Rule #9: develop observable services Key Health check invoker, e.g. monitoring service Invokes Observable Service Health Check API Health Check API pattern Log ﬁle Logging server Log aggregation pattern Exception Reporter Exception Tracking Service Exception Tracking pattern Audit Database Adapter Audit Logging pattern Metrics Exporter Metrics service Application Metrics pattern Distributed Tracing Exporter Distributed tracing server Distributed tracing pattern Logging Aggregation Pipeline Logging Adapter Pattern Developer responsibility Operations responsibility Auditing Database Pattern Participant

Slide 53

Slide 53 text

Why observable services? (Fast) feedback is a foundation of DevEx and DevOps Quickly detect, diagnose and fi x production issues http://itrevolution.com/devops-handbook Flow Feedback Learning

Slide 54

Slide 54 text

@crichardson Rule #10: Incrementally migrate from a monolith to microservices 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

Slide 55

Slide 55 text

Why is the Strangler Fig application pattern better than a big bang rewrite? Acknowledges that modernization is a process of discovery Immediate bene fi t from services Enables agility Early and continuous feedback and learning https://microservices.io/post/refactoring/2023/06/21/strangler- fi g-application-pattern-incremental-modernization-to-services.md.html

Slide 56

Slide 56 text

@crichardson Agenda Development rules A really brief overview of software architecture Rule: use a rational design process Architecture rules Rule: Track and improve software metrics and KPIs

Slide 57

Slide 57 text

@crichardson Track DORA metrics Deployment frequency - how frequently changes are pushed to production Lead time - time from commit to deploy Change failure rate - how frequently a change breaks production Time to restore service - how long to recover from a failed deployment https://dora.dev/

Slide 58

Slide 58 text

@crichardson 2023 State of DevOps report

Slide 59

Slide 59 text

@crichardson Statistical averages hide what good looks like Deployment frequency - for each commit Lead time - under an hour Change failure rate - really low Time to restore service - really short https://dora.dev/

Slide 60

Slide 60 text

@crichardson Assess DevEx https://queue.acm.org/detail.cfm?id=3595878

Slide 61

Slide 61 text

@crichardson Capture architecture metrics Key focus: design-time coupling between services Predict from design metrics Observe actual issues

Slide 62

Slide 62 text

@crichardson Order Service Git Repository Customer Service Git Repository Evaluating design-time coupling: analyzing Git commits JIRA issue Implement X Git commit Git commit Frequent lock-step changes indicate tight design-time coupling

Slide 63

Slide 63 text

Measure directly: frequency of breaking API changes Quanti fi ed: Interval between breaking API changes % commits Subjective: Never Rarely … Often Service Dependency Client API change Pass thru API change Impacts clients Impacts service

Slide 64

Slide 64 text

@crichardson Evaluating design-time coupling: metrics Service Surface area/API complexity # Inbound dependencies Number of operations Number of events Number/Complexity of objects/relationships Client API Degree of exposure = API Complexity / Implementation Complexity Complexity of dependency # Outbound dependencies Number of operations Number of events Number/Complexity of objects/relationships Dependency Dependencies Transitive Dependency Transitive Client

Slide 65

Slide 65 text

Organizational KPIs Software delivery performance impacts business success → Every leader including CxOs should pay attention Category KPI Delivery Lead time Deployment frequency DevEx Perceived ease of delivery Perceived productivity Architecture Degree of loose design-time coupling

Slide 66

Slide 66 text

Summary: microservices rules Development rules Continuously deliver/deploy Implement fast, automated deployment pipelines Organize into small, autonomous, loose-coupled teams Provide a great developer experience (DevEx) Architecture rules Design independently deployable services Design loosely coupled services Design testable services Develop observable services Incrementally migrate from a monolith to microservices Rule: Track and improve software metrics and KPIs Rule: Use a rational design process

Slide 67

Slide 67 text

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