@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

@crichardson Presentation goal Fast Flow: What is it? Why does it matter? Fast fl ow architecture Enables Enables

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

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

@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

@crichardson The software delivery feedback loop Development Production Changes Feedback Users

@crichardson Traditional software delivery, especially outsourced IT projects Changes Feedback Long Infrequent Occasional e.g. every 1 or 2 years Development Production Feedback Users

@crichardson Volatile Uncertain Complex Ambiguous Building complex applications Often using new, unfamiliar technologies + Slow feedback loops = Build the wrong application, the wrong way

@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

@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

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

@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

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

@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

@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

@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

@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

@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

@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

@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

@crichardson Monolithic architecture: one component Production Deployment pipeline Application repository Developer laptop App

@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

@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

@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

@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

@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?

@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

@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

@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

@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 ❌

@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 ✅

@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

@crichardson Pattern: Domain module Facade API • Iceberg like • Good encapsulation ✅ • Mockable

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»

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 ✅

@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

@crichardson Designing a microservice architecture: key goal Simplistic subdomain => service risks creating a distributed monolith Careful design is needed

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

@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

@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

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

@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

@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

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