Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Microservices: what does good look like? (Nov 2...

Microservices: what does good look like? (Nov 2023)

The microservice architecture has become increasingly popular over the past decade. Its key benefits include significantly improving the developer experience and accelerating software delivery. Sadly, however, microservices have often been widely misunderstood and used inappropriately. As a result, many organizations have struggled to benefit from their adoption.

In this presentation I'll describe the key characteristics of the microservice architecture and how it differs from the monolithic architecture. You will learn when you should use microservices and when you should not. I'll describe the ideal developer experience when using the microservice architecture.You will also learn what other changes you must make to your organization when adopting microservices.

Chris Richardson

December 04, 2023
Tweet

More Decks by Chris Richardson

Other Decks in Programming

Transcript

  1. @crichardson Microservices: what does good look 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 © 2023. Chris Richardson Consulting, Inc. All rights reserved
  2. @crichardson Presentation goal Why is rapid, frequent, reliable and sustainable

    delivery of software essential? What does that mean for software architecture? Compare and contrast architectural patterns: Monolithic architecture and Microservice architecture
  3. @crichardson Agenda Modern software delivery Architecting for modern software delivery

    The monolithic architecture is not an anti-pattern The microservice architecture pattern
  4. @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: ???
  5. @crichardson Quantifying with the 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/
  6. @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/
  7. The research shows: high-performance = $$$ Software Delivery Performance Lead

    time, Deployment frequency, Mean Time To Restore, Change Failure % Organizational Performance Pro fi tability, Productivity, Market share $ Impacts
  8. 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
  9. @crichardson DevOps: automated continuous deployment + telemetry Production Commit code+tests

    frequently to trunk Automated deployment pipeline Continuous integration Tests + static analysis (Git) repository for Code AND Infrastructure con fi guration (e.g. GitOps) No handoffs Automated deployment Canary releases Observability infrastructure Telemetry Developer
  10. @crichardson DevOps: Hypothesis-driven development Microsoft study: 2/3rds of ideas have

    zero or negative value. HiPPO (highest paid person's opinion) is too common Therefore: Treat requirements as hypothesis Run as-cheap-as-possible experiments in production with users Base decisions on data gathered
  11. Big idea: fast feedback Getting changes into production as fast

    as possible after writing it Validates what was written: code, feature, … Change is still fresh in the mind of the developer Big task => series of very small tasks
  12. High performance organization: team of teams 5-9 people - promotes

    trust Long-lived - enables trust and high performance Empowered/autonomous Typically owns suitably sized software “component” Promotes long-term sustainable development Prevents cognitive overload https://teamtopologies.com/key-concepts
  13. Development in high performing organizations “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 signi fi cant 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.”
  14. @crichardson Developer experience (DevEx) encompasses how developers feel about, think

    about, and value their work. https://queue.acm.org/detail.cfm?id=3595878
  15. @crichardson Great DevEx Developers can focus with minimal interruptions Minimal

    unnecessary cognitive load Fast feedback from local tools, deployment pipeline, production environment, …
  16. @crichardson But we are a bank: we can’t do DevOps?!

    Yes you can! • Customer facing application servicing over 80 million accounts. • 25 Agile teams with approx .150+ engineers geographically distributed. • Reactive based micro services architecture in the Cloud • 60 deployment pipelines - ~4300 releases over the last 12 months • Mature engineering practices • Automated control gates. https://itrevolution.com/articles/biz-and-tech-partnership-toward-ten-no-fear-releases-per-day-at-capital-one/ https://videos.itrevolution.com/watch/468711236/ US$38.37 billion 50K people e.g. Need two person approval => pair programming
  17. @crichardson Agenda Modern software delivery Architecting for modern software delivery

    The monolithic architecture is not an anti-pattern The microservice architecture pattern
  18. 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 Primary goal = satisfy non-functional requirements
  19. @crichardson Architectural requirement #1: 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
  20. @crichardson Loose coupling is a fundamental principle of software design

    Ignore at your peril! of classes, packages, modules, services, applications, … V
  21. @crichardson Architectural requirements #2 and #3: 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
  22. @crichardson Successful applications live for a long time, e.g. 10

    years, 20 years, … BUT Technology changes: Programming languages, frameworks, … Time Technology A Technology B V1 V2 V3 V… Importance The importance of a technology changes over time Relying on technology that is unimportant to market Not using technology that is important to the market Murer, Stephan,Bruno Bonati Consulting, Bruno Bonati. Managed Evolution: A Strategy for Very Large Information Systems
  23. @crichardson Architecting for sustainable software development Evolvability Must be able

    to incrementally upgrade the technology stack API encapsulates the technology stack
  24. @crichardson Agenda Modern software delivery Architecting for modern software delivery

    The monolithic architecture is not an anti-pattern The microservice architecture pattern
  25. @crichardson The monolith architecture An architectural style that structures the

    application that structures the application as a single deployable/ executable component that uses a single database.
  26. @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 Modular monolith: domain-oriented not layered Promotes loose build-time coupling Vertical slices/domains Clear ownership Single large repo Slow or complicated https://microservices.io/post/architecture/2023/07/31/how-modular-can-your-monolith-go-part-1.html
  27. @crichardson Dif fi cult to achieve fast feedback Production Git

    push con fl icts SLOW deployment pipeline SLOW local development Becomes a bottleneck Infrequent Deployments
  28. @crichardson Lack of team autonomy Large monolith code base 100s

    of developers Modular design can help but there’s only a single code base, … “Oops I broke the build” “We need to upgrade dependency X” …
  29. @crichardson Developer experience: monolithic architecture 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
  30. @crichardson Single technology stack Monolith Application code Framework X Vn

    Framework Y Vn Library Z Vn Language runtime v … Upgrades are global = potentially large task Can’t experiment with alternative frameworks or languages
  31. @crichardson Agenda Modern software delivery Architecting for modern software delivery

    The monolithic architecture is not an anti-pattern The microservice architecture pattern
  32. @crichardson The microservice architecture An architectural style that structures the

    application as a collection of two or more independently deployable loosely coupled services
  33. @crichardson API Service de fi nition Operations Event Publisher Commands

    Queries Synchronous REST/gRPC Asynchronous Messaging Events Event Subscriber API Client Invokes Operations Events Collaborators Responsibilities «subdomain» Order Management «subdomain» Customer Management Business logic
  34. @crichardson Independently deployable = production- ready after being tested in

    isolation https://microservices.io/post/architecture/2022/05/04/microservice-architecture-essentials-deployability.html
  35. Loosely (design-time*) coupled Changing services in lock step reduces productivity:

    API changes/evolution Complexity of non-atomic changes of independently deployable services Coordination between teams Therefore: Tightly coupled subdomains should be packaged together Services should have small, stable APIs * 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 Loose coupling is essential
  36. @crichardson Microservice architecture != lots of little services Service Service

    Subdomain A Subdomain B Team A Team B Service Subdomain A Subdomain B OR Team A Team B #itDepends
  37. @crichardson A service exists to solve a problem 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 https://microservices.io/post/architecture/2023/03/26/dark-energy-dark-matter-force-descriptions.html
  38. @crichardson A service should not exist if it creates worse

    problems 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 Efficient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Generates SystemOperation() Collaboration Attractive dark matter forces
  39. @crichardson Message Broker Consequences of distribution: distributed operations Order Service

    createOrder() Restaurant Service Customer Service GET /restaurant/{id} The network: • Complexity • Partial failure • Runtime coupling • Latency • Performance • …
  40. @crichardson Consequences of independent deployability: no end-to-end tests Consumer Provider

    (service) Test in isolation Consumer-driven contract testing Test in isolation Contract = example interaction Testing in production: • Separate deployment from release • Canary release • Feature fl ags • Chaos engineering • …
  41. @crichardson Consequences of loose design-time coupling: database per service with

    eventual consistency Order Service Customer Service Orders Database Customers Database API createOrder() reserveCredit() BEGIN transaction … COMMIT transaction BEGIN transaction … COMMIT transaction
  42. @crichardson Distributed operation => use collaboration patterns API Composition Provider

    Service Service query() Composer Provider Service Provider Service CQRS Provider Service Service query() View Provider Service Provider Service Event Event Event Service Service Service Transaction Compensating transaction Transaction Compensating transaction Transaction Compensating transaction command() Saga Service Service command() Replica Source Event Command-side replica Commands Queries https://microservices.io/post/patterns/2023/07/29/service-collaboration-patterns.html
  43. @crichardson Developer experience: microservice architecture 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
  44. @crichardson Focus on internal functionality - not collaboration Loosely coupled

    Service A P I Tightly coupled Service API Good ✅ Bad ❌ Constant collaboration with other teams Mostly works independently Subdomain X Subdomain Y Subdomain Z Focus Focus
  45. @crichardson Collaborate to de fi ne APIs For example: Order

    Management must invoke new Coupon Management to redeem coupon Teams meet to co-create contracts (example request/ responses) that de fi ne redeemCoupon() API endpoint Teams then work independently: Order Service team - write biz logic using test doubles Coupon Service team - implement redemption logic
  46. @crichardson Per-service technology stack management Upgrading the technology stack can

    be done one service at time, e.g. Spring Boot 2.7.x to 3.x Safely experiment with new technologies Implement a service using a new technology Minimal investment Easily reversed if experiment fails
  47. @crichardson Summary Modern software development IT must deliver software rapidly,

    frequently, reliably, and sustainably DORA Metrics Lead time Deployment frequency Change failure rate Mean time to recover Measured by Outcome Better business performance $$$$$ profitability, productivity, and market share Correlates with
  48. @crichardson Summary Modern software development IT must deliver software rapidly,

    frequently, reliably, and sustainably DORA Metrics Lead time Deployment frequency Change failure rate Mean time to recover Measured by Outcome Better business performance $$$$$ profitability, productivity, and market share Correlates with Achieved using Process: DevOps Organization: A network of small, loosely coupled, teams Architecture Success Triangle Great DexEx Fast feedback Frequent flow state Low cognitive load
  49. @crichardson Summary Modern software development IT must deliver software rapidly,

    frequently, reliably, and sustainably DORA Metrics Lead time Deployment frequency Change failure rate Mean time to recover Measured by Outcome Better business performance $$$$$ profitability, productivity, and market share Correlates with Achieved using Process: DevOps Organization: A network of small, loosely coupled, teams Architecture Success Triangle Great DexEx Fast feedback Frequent flow state Low cognitive load Architectural requirements Testable Deployable Observable Loosely coupled Evolvable Simple
  50. @crichardson Summary Modern software development IT must deliver software rapidly,

    frequently, reliably, and sustainably DORA Metrics Lead time Deployment frequency Change failure rate Mean time to recover Measured by Outcome Better business performance $$$$$ profitability, productivity, and market share Correlates with Achieved using Process: DevOps Organization: A network of small, loosely coupled, teams Architecture Success Triangle Great DexEx Fast feedback Frequent flow state Low cognitive load Architectural requirements Testable Deployable Observable Loosely coupled Evolvable Simple Shaped by Smaller/Simpler Applications Large/Complex applications Independently deployable Loosely coupled Monolith Microservices Subdomain A «Aggregate» X Subdomain B «Aggregate» Y Service A Service B Attraction Simple interactions Prefer ACID over BASE Minimize runtime coupling Efficient inter-service communication Minimize design time coupling Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Cost effective scaling Segregate regulated software Segregate highly available components Repulsion Metaphor for Metaphor for Dark energy Dark matter