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

Microservices rules (July 2024) : what good loo...

Microservices rules (July 2024) : what good looks like

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. I’ve had numerous conversations where developers have complained that their new microservices-based applications are difficult to change.

In this presentation, I describe 11 development and architecture rules (a.k.a. best practices) that should prevent an organization from making a mess of its microservice architecture. I say should because given semantic diffusion and incredible ability of many organizations to misinterpret and misapply rules, there are no guarantees. However, I believe that if an organization follows these rules when adopting microservices, it will increase their chance of success.

Chris Richardson

July 10, 2024
Tweet

More Decks by Chris Richardson

Other Decks in Programming

Transcript

  1. @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 July 2024
  2. @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
  3. @crichardson Presentation goal 11 rules that prevent an organization from

    making a mess of its microservice architecture
  4. @crichardson Agenda Development rules for fast fl ow A really

    brief overview of software architecture Rule: use a rational design process Architecture rules Rule: Track and improve software metrics and KPIs
  5. @crichardson Traditional software delivery, especially outsourced IT projects Changes Feedback

    Long Infrequent Occasional e.g. every 1 or 2 years Development Production Feedback Users
  6. @crichardson Volatile Uncertain Complex Ambiguous Building complex applications Often using

    new, unfamiliar technologies + Infrequent feedback = Risk of building the wrong application, the wrong way
  7. @crichardson Fast fl ow for business succe$$ Development Production Continuous

    stream of small changes, many times a day Continuous feedback and learning https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/developer-velocity-how-software-excellence-fuels-business-performance Users
  8. @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 continuously deliver a stream of small changes to customers Businesses must be nimble, agile and innovate faster S/W VUCA Architecture: ??? Enables Enables
  9. 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
  10. @crichardson Rule #1: Practice 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 https://continuousdelivery.com/
  11. @crichardson Rule #2: Implement a fast deployment pipeline Production Fast,

    automated deployment pipeline Developer laptop Application repository 15 minutes
  12. Rule #3: Apply Team Topologies: organizing for fast fl ow

    https://teamtopologies.com/key-concepts Stream-aligned team, e.g. Order Management Team Requirements Develop Test Deploy Code in production Work High trust/psychological safety: Small 5-9 people, long lived Stream-aligned team Platform team Facilitating Collaboration Sometimes Sometimes Enabling Team Platform team API Tools Complicated Subsystem team Stream-aligned team API XaaS Mostly
  13. @crichardson Rule #4: Provide a great DevEx “Developer experience (DevEx)

    encompasses how developers feel about, think about, and value their work.” Happier developers = more productive developers https://premium.microservices.io/doing-more-with-less-part-1-improving-developer-experience-devex/
  14. @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
  15. @crichardson Agenda Development rules for fast fl ow A really

    brief overview of software architecture Rule: use a rational design process Architecture rules Rule: Track and improve software metrics and KPIs
  16. @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 • … Non-functional requirements Runtime • Scalability • Performance • Availability • … Satis fi es Architecture Focus
  17. @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
  18. @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
  19. @crichardson De fi ning components = grouping subdomains ≪subdomain≫ Customer

    management ≪aggregate≫ Customer ≪subdomain≫ Order management ≪aggregate≫ Order Customer Team Order Team Application Component ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ How to group subdomains into components? Component Component Deployable, Executable, e.g. WAR fi le, executable JAR, … • Loosely coupled • Testable • Deployable Module, eg. JAR fi le
  20. @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
  21. @crichardson Agenda Development rules for fast fl ow A really

    brief overview of software architecture Rule: use a rational design process Architecture rules Rule: Track and improve software metrics and KPIs
  22. Understand the context Define the problem Define evaluation criteria Find

    candidate solutions Evaluate the trade-offs Pick the best solution Document decision 1 2 3 4 5 6 7 Rational decision making Rule #5: use a rational design process 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 … https://microservices.io/post/architecture/2023/03/13/better-decision-making-with-patterns.html Requires knowledge Only you know this
  23. @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 autonomy 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
  24. @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 • ...
  25. @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? …
  26. @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
  27. @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
  28. 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/
  29. @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
  30. @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 Efficient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Attractive dark matter forces SystemOperation() Generates Risk of higher cognitive load Requires stable domain
  31. @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
  32. @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
  33. @crichardson Agenda Development rules for fast fl ow A really

    brief overview of software architecture Rule: use a rational design process Architecture rules Rule: Track and improve software metrics and KPIs
  34. @crichardson Architecture rules #6 Design loosely coupled services #7 Design

    independently deployable services #8 Design testable services #9 Develop observable services #10: Big/risky change => smaller/safer changes De fi ning characteristics of microservices
  35. 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
  36. 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
  37. 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
  38. @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
  39. @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
  40. @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
  41. @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 file 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
  42. 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
  43. @crichardson Example: 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
  44. 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
  45. @crichardson Agenda Development rules for fast fl ow A really

    brief overview of software architecture Rule: use a rational design process Architecture rules Rule: Track and improve software metrics and KPIs
  46. @crichardson DORA metrics: measuring performance https://dora.dev/ Metric Description Elite performance

    Deployment frequency How frequently changes are pushed to production Each commit Lead time Time from commit to deploy < 1 hour Change failure rate How frequently a change breaks production Very low Time to restore service How long to recover from a failed deployment Very short Move fast, don’t break things
  47. @crichardson Capture architecture metrics Key focus: design-time coupling between services

    Predict from design metrics Analyze inbound/outbound dependencies Observe actual issues Commits for multiple services for the same JIRA issue Frequency of breaking API changes
  48. Organizational KPIs Software delivery performance impacts business success THEREFORE: 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
  49. Summary: microservices rules Development rules for fast fl ow 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 Big/risky change => smaller/ safer changes Rule: Track and improve software metrics and KPIs Rule: Use a rational design process