TDC2020 - The microservice architecture: enabling rapid, reliable, frequent and sustainable development
6 likes3,024 views
The document discusses the microservice architecture, highlighting its benefits for enabling rapid, reliable, and frequent software delivery. It outlines key principles, practices, and challenges associated with microservices, emphasizing team autonomy and the importance of loose coupling. The architecture aims to improve maintainability, testability, and deployability while allowing organizations to adapt to changing technologies and market demands.
TDC2020 - The microservice architecture: enabling rapid, reliable, frequent and sustainable development
- 1. @crichardson The microservice architecture: enabling rapid, 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 © 2020. Chris Richardson Consulting, Inc. All rights reserved
- 2. Presentation goal Microservice architecture: • Trends driving adoption • Essential characteristics • Benefits and drawbacks
- 4. @crichardson For slides, more information, raffle, discounts, … Raffle: 5 ebooks + 40% discount Raffle: 2 free spots + 20% discount https://bit.ly/tdc-2020-msa
- 5. Agenda The need to deliver software rapidly, frequently and reliably Developing long-lived applications The monolithic architecture is not an anti-pattern Overview of the microservice architecture Architecting loosely coupled services
- 9. @crichardson Businesses must be nimble, agile, and innovate faster IT must deliver software rapidly, frequently and reliably
- 10. @crichardson Quantifying rapid, frequent and reliable delivery Velocity Lead time - time from commit to deploy Deployment frequency - deploys per developer per day Reliability Mean time to recover from a deployment failure (MTTR) Change failure rate - % of deployments that cause an outage Key Lean* principles * Inspired by the Toyota Production System
- 11. @crichardson Modern software development: rapid and reliable Faster More reliable
- 12. The research shows… Software Delivery Performance Lead time, Deployment frequency, Mean Time To Restore, Change Fail % Organizational Performance Profitability, Productivity, Market share $ Impacts
- 13. @crichardson Process: Lean/DevOps/Continuous Delivery & Deployment Organization: Small, long- lived, product-centric, autonomous teams Architecture: ??? Deliver changes to long-lived applications rapidly, frequently and reliably
- 14. What is DevOps? Set of practices where developers, testers (dev) and IT operations (ops) collaborate and communicate to deliver software rapidly, frequently, and reliably http://itrevolution.com/devops-handbook
- 15. Key DevOps practices ApplicationAutomated deployment pipeline Repository Production Frequent Commits Code and configuration Reliable and frequent deployments Fast and reliable automated tests
- 16. DevOps practices: hypothesis driven development and A/B testing A requirement is a hypothesis that’s often wrong Validate by quickly getting feedback for real users Eric Ries. The Lean Startup (p. 75). increase in revenue = frequency of experiments x idea success rate x idea impact
- 17. High performance organization: team of teams 5-9 people - promotes trust Long-lived - enables trust and high performance Cross functional/autonomous - eliminates time consuming hand-offs Owns suitably sized software “component” Promotes long-term sustainable development Prevents cognitive overload
- 18. @crichardson Case study: amazon.com Amazon reorganized itself into long- lived, product-centric, loosely coupled, autonomous, two pizza teams that developed microservices. By 2015, they were deploying 130,000 times/day! This ability to delivery software rapidly frequently and reliably enables them to dominate retail as well as cloud computing. Rossman, John. Think Like Amazon: 50 1/2 Ideas to Become a Digital Leader DevOps Handbook, Kim et all
- 19. Development in high performing 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.”
- 20. 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
- 21. Agenda The need to deliver software rapidly, frequently and reliably Developing long-lived applications The monolithic architecture is not an anti-pattern Overview of the microservice architecture Architecting loosely coupled services
- 22. @crichardson Successful applications live for 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
- 23. @crichardson An organization’s technology must be aligned with the marketplace Murer, Stephan,Bruno Bonati Consulting, Bruno Bonati. Managed Evolution: A Strategy for Very Large Information Systems Relying on technology that is unimportant to market Not using technology that is important to the market
- 24. @crichardson Must be able to upgrade the technology stack
- 25. @crichardson Required architectural quality attributes (a.k.a. -ilities) Long-lived applications Modularity Incrementally upgrade the technology stack API encapsulates the technology stack
- 26. @crichardson Architecting for rapid, frequent, reliable and sustainable development Loosely coupled (Conway’s law) Modular Testable Deployable API encapsulates • design decisions • technology stack
- 27. Agenda The need to deliver software rapidly, frequently and reliably Developing long-lived applications The monolithic architecture is not an anti-pattern Overview of the microservice architecture Architecting loosely coupled services
- 28. @crichardson Tomcat/App. Server Food To Go: Monolithic architecture Browser/ Client WAR/EAR MySQL Database Delivery management Order Management Kitchen Management Web UI Restaurant Management HTML REST/JSON The application The monolithic architecture is an architectural style that structures the application as a single executable/ deployable component
- 29. -ilities of small monoliths Testability Deployability Maintainability Modularity Evolvability ✅ ✅ ✅ ✅ ✅
- 30. @crichardson Rapid, frequent and reliable delivery eventually becomes impossible Time Maintainability Testability Deployability Modularity Evolvability Size/ Complexity -ilities required to be competitive Risk of disruption
- 31. @crichardson MyApp.war Modular monolith = single classpath No guarantee of composability Orders.jar Customers.jar Orders.jar Customers.jar Test independently Still work? + dependencies + dependencies
- 32. @crichardson Technology stack becomes increasingly obsolete BUT a rewrite is not feasible
- 33. @crichardson Many decisions are global and can’t be changed incrementally Don’t change Programming language Application framework Library and framework version …
- 34. @crichardson Monolithic hell By John Martin, Public Domain, https://commons.wikimedia.org/w/index.php?curid=3353638
- 35. Agenda The need to deliver software rapidly, frequently and reliably Developing long-lived applications The monolithic architecture is not an anti-pattern Overview of the microservice architecture Architecting loosely coupled services
- 36. The microservice architecture is an architectural style that structures an application as a set of services that are Highly maintainable and testable Minimal lead time Loosely coupled Independently deployable Implements a business capability Owned/developed/tested/deployed by a small team
- 37. @crichardson Food to Go: Microservice architecture Browser Mobile Application Content Router API Gateway Order Service Restaurant Service Delivery Service … Service Order Database Restaurant Database Delivery Database … Database HTTP /HTML REST REST Browse & Search WebApp Restaurant Detail WebApp …. JavaScript Message Broker
- 38. @crichardson API The structure of a service Operations Event Publisher Commands Queries Synchronous REST/gRPC Asynchronous Messaging Events Event Subscriber API Client Invokes Operations Events Service Database Private!
- 39. @crichardson Service architecture “mirrors” the business FTGO business Kitchen Service Delivery Service Order Taking Kitchen Delivery Accounting …. …. Service Order Service Accounting Service Maps to Maps to Maps to Maps to Maps to Area of the business, a.k.a. Subdomain or Business Capability
- 40. @crichardson Goal is team autonomy one service per team Service https://microservices.io/patterns/decomposition/service-per-team.html Owned by a team Owns one service Not to exceed cognitive capacity of team
- 41. @crichardson Split service only to solve a problem Team become two large split team, split service Deployment pipeline takes too long split into two services that can be developed/tested independently Polyglot development: e.g. Python ML model in a Java application Split for fault tolerance - isolate HA parts of the application …
- 42. Benefits of microservices Improved maintainability Each service fits in the heads of the development team = Easier to understand and change Preserves modularity since a service is a well-defined module with an impermeable API Improved testability: Each service is easier to test and faster to test Improved evolvability - evolve each service’s technology stack independently Improved deployability Each service can be deployed independently Easier to scale application Each service can be scaled independently Improves availability/fault isolation and latency Critical services are isolated from less critical services: separate processes and infrastructure Separate deployments reduces risk of change based failure
- 43. @crichardson Process: Lean + DevOps/Continuous Delivery & Deployment Architecture: microservices Testability Deployability Modularity Deliver changes to long-lived applications rapidly, frequently and reliably Organization: Small, long- lived, product-centric, autonomous teams
- 44. @crichardson Loosely coupled teams and services Order Service Orders Team Automated deployment pipeline Source code repository Kitchen Service Kitchen Team Automated deployment pipeline Source code repository Delivery Service Delivery Team Automated deployment pipeline Source code repository Working independently > 80% of the time
- 45. @crichardson Microservices experiment safely and evolve the technology stack Java Java Java Java Java Golang “GoLang is cool!” Java Java Java “Kotlin is better!” Java Kotlin
- 46. @crichardson Drawbacks of microservices Complexity Development: IPC, partial failure, distributed data Testing: Integration, end to end, … Deployment …
- 47. @crichardson …Drawbacks of microservices Correctly identifying service boundaries and avoiding the distributed monolith anti-pattern Refactoring a monolithic application to a microservice architecture
- 48. @crichardson If you are developing a long-lived, large/complex application AND you need to deliver it rapidly, frequently and reliably THEN the Microservice Architecture is often a good choice
- 49. Agenda The need to deliver software rapidly, frequently and reliably Developing long-lived applications The monolithic architecture is not an anti-pattern Overview of the microservice architecture Architecting loosely coupled services
- 50. @crichardson About Conway’s Law “organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.” http://melconway.com/Home/Home.html Loosely coupled teams require a loosely coupled architecture
- 51. @crichardson Loose coupling is essential Services collaborate, e.g. Order Service must reserve customer credit Coupling is inevitable BUT Services must be loosely coupled API Order Service Customer Service reserveCredit()
- 52. Runtime coupling Order Service cannot respond to a synchronous request (e.g. HTTP POST) until Customer Service responds VS Design time coupling Change Customer Service change Order Service
- 53. @crichardson Loose coupling - design time Design-time coupling requires coordination between teams: e.g. Meetings to discuss API changes Slows down development Essential to minimize design time coupling: Use well-designed, stable APIs Be careful with shared libraries - best for utilities
- 54. Design iceberg services Implementation DB API Small, stable API Large, complex implementation Change What’s hidden can easily be changed
- 55. Avoid shared libraries containing business logic Shared utility libraries ✅ Shared libraries containing business logic that changes requires multiple services to change in lock step ❌ Service A Library Service B Library Service … Library Change
- 56. Avoid shared database tables Order Service Customer Service Database Customer table Tight design- time/runtime coupling Order Service Customer Service Order database Order table Customer database Customer table APIs only
- 58. @crichardson The trouble with synchronous IPC : runtime coupling => reduced availability Order Service Customer Service PUT /customer/id/credit availability(createOrder) = availability(OrderService) x availability(CustomerService) POST /order 😢 Order Customer creditLimit availableCredit
- 59. Problem: Developers treat services as if they are programming language-level modules (that communicate via HTTP) Consequences: IPC is relatively expensive high latency Synchronous communication temporal coupling reduced availability - serviceAvailabilitynumber of services Anti-pattern: Distribution is free
- 60. @crichardson Self-contained service: Can handle a synchronous request without waiting for a response from another service https://microservices.io/patterns/decomposition/self-contained-service.html
- 61. @crichardson Order Service Order Management Customer Management Improving availability: replace service with module POST /order Order Customer creditLimit availableCredit availability(createOrder) = availability(OrderService) More available 😄 Larger service/ team 😢 Response = validation outcome 😄
- 62. @crichardson messaging system Use asynchronous messaging Sender Recipient Message Channel Payload Header http://bit.ly/books-eip Channel types: • Point-to-point • Publish/Subscribe
- 63. @crichardson Improving availability: sagas Order Service Customer Service availability(createOrder) = availability(OrderService) POST /order Credit Reserved More available 😄 Complexity of sagas 😢 Order created Response =! Validation outcome 😢 Order events Customer events https://microservices.io/patterns/data/saga.html
- 64. @crichardson Improving availability: CQRS Order Service Customer Service availability(createOrder) = availability(OrderService) POST /order Customer Created More available 😄 Complex/Costly 😢 Response = validation outcome 😄 Customer creditLimit availableCredit Replicated Owned Customer creditLimit availableCredit Credit Limit Changed https://microservices.io/patterns/data/cqrs.html
- 66. @crichardson Summary: What is the microservice architecture? The microservice architecture is an architectural style that structures an application as a set of services that are • Highly maintainable and testable • Minimal lead time • High deployment frequency • Loosely coupled • Independently deployable • Implements a business capability • Owned/developed/tested/deployed by a small team
- 67. @crichardson Summary: Why should you care about the microservice architecture? Process: Lean + DevOps/Continuous Delivery & Deployment Architecture: microservices Testability Deployability Modularity Modularity Evolvability Maintainability Availability Deliver changes to long-lived applications rapidly, frequently and reliably Organization: Small, long- lived, product-centric, autonomous teams Organizational Performance