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

SDCon2024: Enabling DevOps and Team Topologies ...

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

In order to thrive in today’s volatile and uncertain world, businesses needs to innovate at a much faster pace. Recognizing this, IT organizations are adopting the principles and practices of DevOps and the organizational patterns defined by Team Topologies. But while DevOps and Team topologies are vital for delivering the fast flow of changes that today’s businesses need, they are insufficient. To prevent applications from becoming obstacles to rapid change, IT must also create architectures that support fast flow.

In this presentation, I describe the architectural requirements that enable DevOps and Team Topologies to deliver a fast flow of changes. You will learn about the forces that shape an architecture and the trade-offs that you will need to make when designing an architecture. I show how to decide between the monolithic and microservice architectural styles. You will learn key monolithic architecture patterns for fast flow. I describe how to design a microservice architecture.

Chris Richardson

July 08, 2024
Tweet

More Decks by Chris Richardson

Other Decks in Programming

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 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
  4. @crichardson Traditional software delivery, especially outsourced IT projects Changes Feedback

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

    new, unfamiliar technologies + Slow feedback loops = Build the wrong application, the wrong way
  6. @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
  7. @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
  8. 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
  9. @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
  10. 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
  11. @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
  12. @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
  13. @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
  14. @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
  15. @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
  16. @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
  17. @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
  18. @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
  19. @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
  20. @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
  21. @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
  22. @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?
  23. @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
  24. @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
  25. @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
  26. @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 ❌
  27. @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 ✅
  28. @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
  29. 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»
  30. 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 ✅
  31. @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
  32. @crichardson Designing a microservice architecture: key goal Simplistic subdomain =>

    service risks creating a distributed monolith Careful design is needed
  33. 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
  34. @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
  35. @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
  36. 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
  37. @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
  38. @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