Download as PDF, PPTX
Uploaded byChris Richardson
iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, frequent and sustainable development
The document discusses architectural patterns for delivering software rapidly, reliably, and sustainably, comparing monolithic and microservice architectures. It emphasizes the importance of architectural requirements, such as scalability and maintainability, and explores concepts like autonomous teams and the balance of attractive and repulsive forces in system design. Additionally, the document highlights strategies for effective communication and deployment pipelines within software systems.
More Related Content
Similar to iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, frequent and sustainable development
iSAQB gathering 2021 keynote - Architectural patterns for rapid, reliable, frequent and sustainable development
- 1. @crichardson Architectural patterns forrapid, reliable, frequent and sustainable development 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 © 2021. Chris Richardson Consulting, Inc. All rights reserved
- 2. @crichardson Presentation goal Why israpid, 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.
- 4. @crichardson Agenda Architectural requirements forrapid, frequent, reliable and sustainable delivery of software Defining an architecture The monolithic architecture is not an anti-pattern The microservice architecture pattern
- 5. @crichardson O V I D - 1 9 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:Lean + 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 • Deployment frequency: >= once per developer/day • < 15 minute lead time • … Architecture: ???
- 6. @crichardson Successful applications livefor 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
- 7. About software architecture “Thesoftware 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
- 8. Architecture = satisfyingnon- functional requirements Nonfunctional requirements Development Runtime Scalability Performance Availability … Maintainability Testability Deployability … Often neglected
- 9. Development in highperforming 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 significant 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.”
- 10. Required architectural quality attributes(a.k.a. -ilities) “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 significant 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.” Loosely coupled (Conway’s law) Modular Testable Deployable API encapsulates design decisions
- 11. @crichardson Architecting for sustainable softwaredevelopment Evolvability/Modularity Must be able to incrementally upgrade the technology stack API encapsulates the technology stack
- 12. Required architectural quality attributes(.a.k.a. -ilities) https://en.wikipedia.org/wiki/Non-functional_requirement DevOps Autonomous Teams Long-lived applications Testability Deployability Maintainability Loose coupling/Modularity Evolvability
- 13. @crichardson Agenda Architectural requirements forrapid, frequent, reliable and sustainable delivery of software Defining an architecture The monolithic architecture is not an anti-pattern The microservice architecture pattern
- 14. @crichardson How to definean Architecture… Application ≪subdomain≫ Customer management ≪aggregate≫ Customer ≪subdomain≫ Order management ≪aggregate≫ Order createCustomer() createOrder() findOrder() findOrderHistory() System operations Distill Requirements Event storming Functional requirements As a consumer I want to place an Order So that I can …. As a Restaurant I want to accept an Order So that I can …. User stories • SLA: Reliability/Latency • Scalability • … System quality attributes The “requests” that the application implements Customer Team Order Team About Subdomains • Business capability/function/etc • Logical view: packages and classes • Team-sized • Loosely coupled (Conways law) 1 2
- 15. @crichardson Application … how todefine an Architecture Application ≪subdomain≫ Customer ≪aggregate≫ Customer ≪subdomain≫ Order ≪aggregate≫ Order createCustomer() createOrder() findOrder() findOrderHistory() System operations Component ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ How to group subdomains into components*? Component Component * Component = deployable, executable, e.g. WAR file, executable JAR, … 3 Deployable, Executable, e.g. WAR file, executable JAR, …
- 16. @crichardson Grouping subdomains into components:together or separate? ≪subdomain≫ Customer ≪aggregate≫ Customer ≪subdomain≫ Order ≪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://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html
- 17. @crichardson Repulsive forces subdomains indifferent services https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html Service Service «Subdomain» A «Aggregate» X «Subdomain» B «Aggregate» Y Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Cost effective scaling Segregate regulated software Segregate highly available components
- 18. @crichardson Attractive forces subdomains insame service https://chrisrichardson.net/post/microservices/2021/04/15/mucon-2021-dark-energy-dark-matter.html System Operation() Service Service «Subdomain» A «Aggregate» X «Subdomain» B «Aggregate» Y Simple interactions Prefer ACID over BASE Minimize runtime coupling Efficient inter-service communication Minimize design time coupling
- 19. @crichardson The role ofthe architect is balance conflicting forces Minimize attraction Service Subdomain Subdomain Minimize repulsion Service Subdomain Subdomain Minimize repulsion Conflicting goals
- 20. @crichardson Choice of architecturalstyles Application Service ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ Service Service Application ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ ≪subdomain≫ Monolithic architecture: One component Microservice architecture: Many components Resolves Potentially neglects Potentially neglects Resolves
- 21. @crichardson Agenda Architectural requirements forrapid, frequent, reliable and sustainable delivery of software Defining an architecture The monolithic architecture is not an anti-pattern The microservice architecture pattern
- 22. @crichardson Starting development ofa monolithic application $ mkdir application $ cd application $ mkdir -p web/src/main domain/src/main persistence/src/main $ vi build.gradle $ mkdir application $ cd application $ curl -G https://start.spring.io/starter.zip -o app.zip $ unzip app.zip OR
- 23. @crichardson Monolithic architecture Github Repository «GradleProject» FtgoApplication «Gradle Subproject» main main «Gradle Subproject» web web .customers web.orders «Gradle Subproject» domain domain. customers domain. orders «Gradle Subproject» persistence persistence. customers persistence. orders Customer team Order team Deployment pipeline Production FTGO Application Executable JAR Technical layers
- 24. @crichardson Monolithic architecture: benefitsand drawbacks Repulsive forces Simple components Team autonomy Fast deployment pipeline Support multiple technology stacks Cost effective scaling Segregate regulated software Segregate highly available components Attractive forces Simple interactions ✅ Prefer ACID over BASE ✅ Minimize runtime coupling ✅ Efficient inter-service communication ✅ Minimize design time coupling ✅ ✅ or ❌ ∝1/ size ✅ or ❌ ∝1/ size ✅ or ❌ ∝1/ size ❌ ❌ ❌ ✅ if role-based deployments
- 25. @crichardson Successful applications typically keepgrowing… Small monolith Large monolith 10s of developers 100s of developers
- 26. @crichardson Large scale development challenges:git pull/push $ git clone …. $ git commit $ git pull $./gradlew precommitTests $ git push Time consuming? Time consuming? All of them? Rejected? use partial /shallow clones Use merge queue
- 27. @crichardson Stateless, ephemeral, e.g.CI-aaS Large scale development challenges: 15 minute lead time Deployment pipeline Compile Download dependencies Start application Run tests lead time ∝ application size Significant Really significant
- 28. @crichardson Accelerating the deployment pipelinewith technology Cache downloaded dependencies between builds Incremental builds - class level dependencies Compilation avoidance - skip recompile if changed dependency is binary compatible Distributed build cache: reuse task output from other/previous build if inputs have not changed Parallelization Single machine - e.g. Gradle Cluster - e.g. Bazel
- 29. @crichardson How to improveteam autonomy? How to accelerate the build without hiring rocket scientists?
- 30. @crichardson Github Repository «Gradle Project» FtgoApplication «GradleSubproject» main main «Gradle Subproject» web web .customers web.orders «Gradle Subproject» domain domain. customers domain. orders «Gradle Subproject» persistence persistence. customers persistence. orders Customer team Order team Deployment pipeline Production FTGO Application Executable JAR Re-examining the architecture One or many One or many per repository Horizontal layers vs vertical slices
- 31. @crichardson Github Repository «Gradle Project» FtgoApplication «GradleSubproject» 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 Defines API Vertical slices/domains Clear ownership Single large repo Slow or complicated
- 32. @crichardson About the CustomerAPI module Service-style facade Promotes loose coupling/ Encapsulation Example: define using Protobuf!! Accelerates builds Test Order module with mock Customer module Changing Customer implementation module won’t trigger rebuild/test of its clients Order Customer API Customer Main X
- 33. @crichardson How modular canyou go: Transaction boundaries? Benefits Drawbacks Per-request • Simple implementation (ACID) • Efficient data access • Tight transaction coupling between modules • More difficult to migrate to services Per module/ aggregate • Loose transaction coupling between modules • Easier to migrate to services Potentially: • More complex implementation (BASE), e.g. Sagas • Inefficient data access
- 34. @crichardson How modular canyou go: interaction styles? Traditional inter-module communication, e.g. Method call that takes parameters and returns some values Caller waits for method to return/not throw exception Risk of tight runtime coupling if module was refactored to a service Consider using asynchronous style of communication: events, async request/response, one-way commands, …
- 35. @crichardson How modular shouldyou go? Transaction per module Asynchronous inter-module communication = Many of the costs/complexities of microservices without the benefits YAGNI - https://martinfowler.com/bliki/Yagni.html ?
- 36. @crichardson Modular monolith usingmulti repos Enforces consistent set of 3rd party dependencies across all projects Defines API Clear ownership Multiple, smaller Simpler, faster Potentially slow/ complicated Maven Repository Github Repository Github Repository Github Repository Github Repository «Gradle project» main main «Gradle project» orders orders.web «Gradle project» customerAPI orders. domain «Gradle project» customers customers. persistence orders. persistence Customer team Order team Deployment pipeline Production FTGO Application Executable JAR customers. domain customers. web customers. api Orders JAR Deployment pipeline Customers API JAR Deployment pipeline Customers JAR Deployment pipeline Github Repository «Gradle project» BOM/Platform Deployment pipeline BOM Artifact
- 37. @crichardson Application-level deployment pipeline Assembles releasedbinary versions of modules to create component, e.g. executable JAR Must validate/test the application/component Key issue is composability: the modules work independently but do they work together? Dependency conflicts: NoSuchMethodError Spring bean name conflicts When are these errors detected: “build time” - ideally, e.g. verify set of transitive dependencies is meaningful On startup - potentially ok Request handling => requires running potentially slow tests
- 38. @crichardson Monolithic architecture: benefitsand drawbacks revisited Repulsive forces Simple components ✅ or ❌ ∝1/ size Team autonomy ✅ or ❌ ∝1/ size Fast deployment pipeline ✅ or ❌ ∝1/ size Support multiple technology stacks ❌ Cost effective scaling ✅ if role-based deployments Segregate regulated software ❌ Segregate highly available components ❌ Attractive forces Simple interactions ✅ Prefer ACID over BASE ✅ Minimize runtime coupling ✅ Efficient inter-service communication ✅ Minimize design time coupling ✅ Modularization + Technology enable the Monolithic Architecture to be used for larger applications BUT the application can ultimately outgrow its architecture when these forces cannot be resolved It can’t resolve these forces
- 39. @crichardson Agenda Architectural requirements forrapid, frequent, reliable and sustainable delivery of software Defining an architecture The monolithic architecture is not an anti-pattern The microservice architecture pattern
- 40. @crichardson Microservice architecture: Many components Production GithubRepository Github Repository «Gradle project» orders orders.web orders. domain «Gradle project» customers customers. persistence orders. persistence Customer team Order team Deployment pipeline «Executable JAR» Order Service customers. domain customers. web customers. main orders.main «Executable JAR» Customer Service Deployment pipeline «Service Instance» Order Service «Service Instance» Customer Service Inter-service Communication Clear ownership Multiple small Simpler, faster Per-service path to production
- 41.
- 42. @crichardson Subdomain Service «subdomain» Order Management «subdomain» Order Management Order Service «subdomain» Money OrderService «subdomain» Money «subdomain» Order Management Customer Service «subdomain» Money «subdomain» Customer Management Normally Sometimes • Same version = coupling ❌ • Different version ✅ Single service
- 43.
- 44.
- 45. @crichardson Microservice architecture: Benefitsand drawbacks Repulsive forces Simple components ✅ Team autonomy ✅ Fast deployment pipeline ✅ Support multiple technology stacks ✅ Cost effective scaling ✅ Segregate regulated software ✅ Segregate highly available components ✅ Attractive forces Simple interactions ❌ Prefer ACID over BASE ❌ Minimize runtime coupling ❌ Efficient inter-service communication ❌ Minimize design time coupling ❌ Must group subdomains to: • Maximize benefits • Minimize drawbacks Potential benefits Potential drawbacks
- 46. @crichardson The challenge =attractive and repulsive forces conflict ≪Complicated≫ Order Mgmt ≪Simple≫ Customer Mgmt ≪Complicated≫ Fulfillment findOrder() createOrder() Order Team Fulfillment Team Customer Team getOrder() createOrder() reserveCredit() getDelivery() scheduleDelivery()
- 47. @crichardson Service Service Service Service Numerous possible groupings ≪Complicated≫ Order Mgmt ≪Simple≫ Customer Mgmt ≪Complicated≫ Fulfillment Service Service Service Service Service Service RepulsionWeakest Strongest ≪Complicated≫ Order Mgmt ≪Complicated≫ Order Mgmt ≪Complicated≫ Order Mgmt ≪Complicated≫ Order Mgmt ≪Simple≫ Customer Mgmt ≪Simple≫ Customer Mgmt ≪Simple≫ Customer Mgmt ≪Simple≫ Customer Mgmt ≪Complicated≫ Fulfillment ≪Complicated≫ Fulfillment ≪Complicated≫ Fulfillment ≪Complicated≫ Fulfillment createOrder() None High (Saga) High (Saga) Medium (notify Fulfillment) High (Saga) findOrder() None None High (API Composition/CQRS) High (API Composition/ CQRS) High (API Composition/CQRS) Attractive forces
- 48. @crichardson Fine-grained decomposition Service Service Service ≪Complicated≫ Order Mgmt ≪Simple≫ Customer Mgmt ≪Complicated≫ Fulfillment Order Team Fulfillment Team Customer Team Zerorepulsive forces ✅ BUT Stronger attractive forces ❌ Eventually consistent saga Multi-service query: Risk: Distributed monolith anti- pattern = Brittle and unproductive
- 49. @crichardson Balancing forces: simplifying createOrder() OrderTeam Fulfillment Team Customer Team Fulfillment Service Order Service ≪Complicated≫ Order Mgmt ≪Simple≫ Customer Mgmt ≪Complicated≫ Fulfillment Reduced autonomy 😢 Fulfillment Service Order Service createOrder() Order Created Simple notification 😀 Still complicated 😢
- 50. Microservices drawbacks: BASEis inherently more complex than ACID ACID transactions Free rollback Databases implement Isolation (I) Isolation: concurrent execution equivalent to some sequential execution e.g. claim locks that are held until commit BUT Typically need compensating transactions Sagas are ACD - Lack of I Each step of a saga is a transaction Concurrent execution of sagas => Potential data anomalies Analyze carefully and select countermeasures = design techniques that provide I
- 51. @crichardson Microservices drawbacks: APIs aremore complicated interface OrderService { … } vs. $ javac Use an inter-service communication library/framework object.method(args) Runtime checking = risk of outages Use consumer-driven contract tests to prevent breaking changes vs. vs. Partial failure, latency, … Complete failure vs.
- 52. @crichardson Application Deployment pipeline Microservices drawbacks:brittle, slow, costly end to end tests Order Service deployment pipeline Customer Service deployment pipeline End to End tests Production Given a customer with an availableCredit of $100 And a product costing $10 When the customer orders the product Then an order is created And the availableCredit becomes $90 Traditional acceptance test Spans services Bottleneck: increases lead time, MTTR
- 53. @crichardson Push acceptance testsdown the pyramid Order Service deployment pipeline Customer Service deployment pipeline Production Given a customer with sufficient credit And a product costing $10 When the customer orders the product Then an order is created And credit was reserved Refactored acceptance test Given a customer with an availableCredit of $100 When the customer reserves $10 Then the availableCredit becomes $90 Refactored acceptance test
- 54. @crichardson Run acceptance testsin production Production Given a customer with an availableCredit of $100 And a product costing $10 When the customer orders the product Then an order is created And the availableCredit becomes $90 Traditional acceptance test
- 55. Order Service V1 Order Service V2 Testdeployed code before releasing: e.g. Canary release 1.Deploy V2 alongside V1 2.Test V2 3.Route test traffic to V2 4.Release V2 to a small % of production users 5.Monitor/test (latency, errors) - undo rollout if errors 6. Increase % of production traffic going to V2 7.Repeat until 100% of traffic going to V2 8.Eventually undeploy V1 Intelligent traffic router Order Service V1 Order Service V2 Monitoring system
- 56.
- 57. @crichardson Summary Architect constantly Evolve yourarchitecture as your requirements change Spectrum of architectural patterns: Monolith Layered monolith Modular monolith Microservices Pick the pattern than balances dark energy and dark matter
- 58.