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.

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 chris@chrisrichardson.net 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 chris@chrisrichardson.net http://adopt.microservices.io Questions?