SDCon2024: Enabling DevOps and Team Topologies thru architecture: architecting for fast flow

Transcript

1. @crichardson Enabling DevOps and Team Topologies thru architecture: architecting for

   fast fl ow Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns @crichardson [email protected] adopt.microservices.io Copyright © 2024. Chris Richardson Consulting, Inc. All rights reserved

2. @crichardson Presentation goal Fast Flow: What is it? Why does

   it matter? Fast fl ow architecture Enables Enables

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

4. @crichardson About Chris https://chrisrichardson.net/

5. @crichardson Agenda Introduction to fast fl ow, DevOps and Team

   Topologies Architecting for fast fl ow Architectural styles for fast fl ow About modular monoliths Designing a microservice architecture

6. @crichardson The software delivery feedback loop Development Production Changes Feedback

   Users

7. @crichardson Traditional software delivery, especially outsourced IT projects Changes Feedback

   Long Infrequent Occasional e.g. every 1 or 2 years Development Production Feedback Users

8. @crichardson Volatile Uncertain Complex Ambiguous Building complex applications Often using

   new, unfamiliar technologies + Slow feedback loops = Build the wrong application, the wrong way

9. @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

10. @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

11. About 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

12. @crichardson Have a fast deployment pipeline Production Fast, automated deployment

    pipeline Developer laptop Application repository 15 minutes Must scale to support rate of Git pushes Measure using the DORA metrics https://dora.dev/ >= 1 commit / developer / day

13. About 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

14. @crichardson Agenda Introduction to fast fl ow, DevOps and Team

    Topologies Architecting for fast fl ow Architectural styles for fast fl ow About modular monoliths Designing a microservice architecture

15. @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

16. @crichardson Architectural requirement: loose coupling Order Management Customer Management Owns

    Owns Unaffected by changes to the other Conway’s law Loosely coupled = work independently Loosely coupled Degree of design-time coupling = probability of lockstep changes

17. @crichardson Software elements should be like icebergs* Implementation Small and

    stable Larger and unstable * Modules should be deep - J. Ousterhout. A Philosophy of Software Design

18. @crichardson Architectural requirements: testable and deployable 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 Agenda Introduction to fast fl ow, DevOps and Team

    Topologies Architecting for fast fl ow Architectural styles for fast fl ow About modular monoliths Designing a microservice architecture

20. @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

21. @crichardson Monolithic architecture: one component Production Deployment pipeline Application repository

    Developer laptop App

22. @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 Some system operations span multiple services

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-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://microservices.io/post/architecture/2023/03/26/dark-energy-dark-matter-force-descriptions.html

24. @crichardson Dark energy and dark matter forces 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 Attraction Simple interactions 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

25. @crichardson Dark energy and dark matter forces <=> fast fl

    ow Dark energy repulsive forces Microservices Monolith Team autonomy ✅ ✅ or ❌ ∝1/ size Fast deployment pipeline ✅ ✅ or ❌ ∝1/ size Segregate by characteristics Software development regulations ✅ ❌ DDD subdomain type ✅ ❌ Dark matter attractive forces Simple interactions Risk of excessive complexity ❌ ✅ Ef fi cient interactions ✅ Prefer ACID over BASE ✅ Minimize runtime coupling ✅ Minimize design time coupling Risk of unstable APIs ❌ ✅ Enable Inhibit

26. @crichardson Your context determines relevance of forces to your application

    Dark energy repulsive forces Relevance to your application determined by Team autonomy ∝Number of teams Fast deployment pipeline Build time ∝ size/complexity of app Build frequency ∝ rate of Git pushes Segregate by characteristics Software development regulations Regulated subdomains? Dark matter attractive forces Simple interactions Do the bene fi ts of distribution outweigh the complexity? Ef fi cient interactions Prefer ACID over BASE Minimize runtime coupling Minimize design time coupling Is the domain well understood?

27. @crichardson Selecting an architectural style 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 What’s the component architecture? Application requirements + Organization Subdomain A «Aggregate» X Subdomain B «Aggregate» Y Service A Service B Attraction Simple interactions 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

28. @crichardson Agenda Introduction to fast fl ow, DevOps and Team

    Topologies Architecting for fast fl ow Architectural styles for fast fl ow About modular monoliths Designing a microservice architecture

29. @crichardson Designing a monolith: key goals Manage complexity Modular architecture

    Encapsulate (hide) the complexity behind small, stable APIs Maximize team autonomy Each team is responsible a well-de fi ned, loosely coupled module Minimize build times Reduce build-time coupling: the modules that must be rebuilt/retested when you make a change one module Carefully design Maven/Gradle dependencies

30. @crichardson Pattern: Traditional layered monolith Application «layer» Web «layer» Domain

    «layer» Persistance/infrastructure Organized around technical layers Consumer team Order team Delivery team DevOps (Stream-aligned) team Consumers Orders Deliveries … Consumers Orders Deliveries … Consumers Orders Deliveries … $ mkdir web $ mkdir domain $ mkdir infrastructure Low autonomy ❌ Poor encapsulation ❌ High build-time coupling ❌

31. @crichardson Pattern: modular monolith «Module» Main System operations: createOrder() cancelOrder()

    findOrderHistory() createConsumer() «Module» Consumer Management «Subdomain» Consumer Management «Aggregate» Consumer «Module» Delivery Management «Subdomain» Delivery Management «Aggregate» Delivery «Aggregate» Courier Consumer team Order team Delivery team Owns Owns Owns «Module» Order Management «Subdomain» Order Management «Aggregate» Order DevOps (Stream-aligned) team Application Owned by all teams Organized around subdomains rather than technology $ mkdir orders $ mkdir consumers $ mkdir deliveries High autonomy ✅

32. @crichardson Domain View: domain modules are top-level packages «package» com.acme.application

    «package» «module» consumers «package» «module» orders «package» «module» deliveries «package» web «package» domain «package» infrastructure «package» web «package» domain «package» infrastructure «package» web «package» domain «package» infrastructure

33. @crichardson Pattern: Domain module Facade API • Iceberg like •

    Good encapsulation ✅ • Mockable

34. Pattern: Private domain module tables Essential for loose design- time

    coupling (Good encapsulation ✅) Violate encapsulation at your peril Database Server «Module» Order Management «Table» Order «Table» OrderLine «Table» Order… Order Management tables Order Management tables «Module» Customer Management Customer Management tables «Table» Customer «FK»

35. Pattern: Domain API Maven/ Gradle module «Gradle project» Customer API

    «Facade» CustomerService «Gradle project» Client «Gradle project» Customer Domain «Facade» CustomerServiceImpl «DTO» CustomerInfo ClientTest Tests Mocks createCustomer() getCustomer() reserveCredit() releaseCredit() «Service» Customer ServiceClient For each module: De fi ne a Domain API Maven/Gradle module/sub-project Clients depend on API module Test clients using a mock API Low build- time coupling ✅

36. @crichardson Agenda Introduction to fast fl ow, DevOps and Team

    Topologies Architecting for fast fl ow Architectural styles for fast fl ow About modular monoliths Designing a microservice architecture

37. @crichardson Designing a microservice architecture: key goal Simplistic subdomain =>

    service risks creating a distributed monolith Careful design is needed

38. 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

39. @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

40. @crichardson Avoid the Distributed monolith anti-pattern: Tightly design-time coupled services

    End-to-end testing before release Friction of the monolith + complexity of microservices

41. Two levels of architecture Service architecture Service de fi nitions

    APIs Responsibilities Collaborations Interaction styles: synchronous vs. asynchronous Technical architecture Choice of speci fi c technologies Synchronous: REST vs. gRPC Pick message broker(s) Deployment technologies … Critical Important vs. Focus

42. @crichardson Assemblage: design process Incrementally de fi nes One operation

    at a time 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 Attraction Simple interactions 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

43. @crichardson Summary Volatile Uncertain Complex Ambiguous Fast flow architecture Modular

    Monolithic architecture Microservice architecture Requires createOrder() createOrder() Subdomain A «Aggregate» X Subdomain B «Aggregate» Y Service A Service B Attraction Simple interactions 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 Creates Dark energy and dark matter Is Fast flow: delivering a continuous stream of changes to customers 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 Uses Architectural requirements: • Loosely coupled • Testable • Deployable • Observable Fast flow Success Triangle Assemblage Defines IS-A

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