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.

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 chris@chrisrichardson.net 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 About Chris http://adopt.microservices.io
4. @crichardson Agenda Modern software delivery Architecting for modern software delivery The monolithic architecture is not an anti-pattern The microservice architecture pattern
5. @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: ???
6. @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/
7. @crichardson 2023 State of DevOps report
8. @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/
9. 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
10. 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
11. @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
12. @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
13. 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
14. 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
15. @crichardson https://teamtopologies.com/key-concepts
16. @crichardson Team interaction: primarily X-as-a Service https://teamtopologies.com/key-concepts
17. @crichardson Teams primarily collaborate to (re)de fi ne APIs
18. 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.”
19. @crichardson Developer experience (DevEx) encompasses how developers feel about, think about, and value their work. https://queue.acm.org/detail.cfm?id=3595878
20. @crichardson https://queue.acm.org/detail.cfm?id=3595878 Minimize meetings, interruptions, …
21. @crichardson Great DevEx Developers can focus with minimal interruptions Minimal unnecessary cognitive load Fast feedback from local tools, deployment pipeline, production environment, …
22. @crichardson Measuring DevEx Survey teams + Gather metrics, e.g. DORA
23. @crichardson https://queue.acm.org/detail.cfm?id=3595878
24. @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
25. @crichardson Agenda Modern software delivery Architecting for modern software delivery The monolithic architecture is not an anti-pattern The microservice architecture pattern
26. 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
27. Architecting for…
28. @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
29. @crichardson Loose coupling is a fundamental principle of software design Ignore at your peril! of classes, packages, modules, services, applications, … V
30. @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
31. @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
32. @crichardson Architecting for sustainable software development Evolvability Must be able to incrementally upgrade the technology stack API encapsulates the technology stack
33. @crichardson Architecting for DevEx https://queue.acm.org/detail.cfm?id=3595878 Loose coupling Testability Deployability Observability Simplicity
34. Architectural requirements Testable Deployable Loosely coupled Evolvable Observable Simple as possible + The usual: Security Scalability Performance …
35. @crichardson Problem: How to organize subdomains into components to meet these requirements?
36. @crichardson Monolith vs. Microservices One component = Monolith Two or components = Microservices
37. @crichardson Agenda Modern software delivery Architecting for modern software delivery The monolithic architecture is not an anti-pattern The microservice architecture pattern
38. @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.
39. @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
40. @crichardson Simple but… successful applications keep growing… Small monolith Large monolith 10s of developers 100s of developers
41. @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
42. @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” …
43. @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
44. @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
45. @crichardson Agenda Modern software delivery Architecting for modern software delivery The monolithic architecture is not an anti-pattern The microservice architecture pattern
46. @crichardson The microservice architecture An architectural style that structures the application as a collection of two or more independently deployable loosely coupled services
47. @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
48. @crichardson Independently deployable = production- ready after being tested in isolation https://microservices.io/post/architecture/2022/05/04/microservice-architecture-essentials-deployability.html
49. @crichardson Replace end-to-end acceptance tests with Per-service acceptance tests
50. 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
51. @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
52. @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
53. @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
54. @crichardson Assemblage: designing a microservice architecture https://microservices.io/post/architecture/2023/02/09/assemblage-architecture-de fi nition-process.html Just enough services
55. @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 • …
56. @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 • …
57. @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
58. @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
59. @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
60. @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
61. @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
62. @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
63. @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
64. @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
65. @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
66. @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
67. @crichardson @crichardson chris@chrisrichardson.net http://adopt.microservices.io Questions?