YOW! Perth: Cubes, Hexagons, Triangles, and More: Understanding the Microservice Architecture Through Shapes
7 likes4,226 views
The document discusses the microservice architecture, emphasizing its essential characteristics and benefits for rapid, frequent, and reliable software delivery. It covers key concepts such as the success triangle, scaling techniques, and design principles, while also addressing the drawbacks and challenges associated with microservices. The presentation highlights the need for automated testing and the integration of DevOps practices within this architectural framework.
YOW! Perth: Cubes, Hexagons, Triangles, and More: Understanding the Microservice Architecture Through Shapes
- 1. @crichardson Cubes, Hexagons, Triangles, and More: Understanding the Microservice Architecture Through Shapes Chris Richardson Founder of Eventuate.io Founder of the original CloudFoundry.com Author of POJOs in Action and Microservices Patterns @crichardson [email protected] https://adopt.microservices.io Copyright © 2019. Chris Richardson Consulting, Inc. All rights reserved
- 2. @crichardson Presentation goal The essential characteristics of the Microservice Architecture
- 4. @crichardson About Chris https://microservices.io/book 40% discount with code ctwyowp19
- 5. About Chris: microservices.io Microservices pattern language Articles Example code Microservices Assessment Platform
- 6. @crichardson Agenda Process Organization Architecture Deliver changes to long- lived applications rapidly, frequently and reliably Success Triangle Scale Cube Hexagonal Architecture API Iceberg services Channel Messaging Unit Integration Component End to End Testing Pyramid
- 7. @crichardson + Marketplace is volatile, uncertain, complex and ambiguous + Businesses must innovate faster Deliver software rapidly, frequently and reliably Software
- 8. @crichardson Quantifying rapid, frequent and reliable delivery Velocity Lead time - time from commit to deploy Deployment frequency - deploys per developer per day Reliability Change failure rate - % of deployments that cause an outage Mean time to recover from a deployment failure
- 9. @crichardson Successful applications often live a very long time Technology changes Need to be able to easily modernize applications +
- 10. @crichardson Success Triangle Process Organization Architecture Deliver changes to long-lived applications rapidly, frequently and reliably
- 11. @crichardson Success Triangle : Lean + DevOps/Continuous Delivery & Deployment Small, autonomous teams : ??? Deliver changes to long-lived applications rapidly, frequently and reliably Process Organization Architecture:
- 12. @crichardson Agenda Process Organization Architecture Deliver changes to long- lived applications rapidly, frequently and reliably Success Triangle Scale Cube Hexagonal Architecture API Iceberg services Channel Messaging Unit Integration Component End to End Testing Pyramid
- 13. 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 Modularity Evolvability
- 14. @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
- 15. -ilities of small monoliths Testability Deployability Maintainability Modularity Evolvability ✅ ✅ ✅ ✅ ✅
- 16. @crichardson But successful applications keep growing…. Development Team Application
- 17. @crichardson … and growing Development Team A ApplicationDevelopment Team B Development Team C
- 18. @crichardson … and modularity breaks down… http://www.laputan.org/mud/ “haphazardly structured, sprawling, sloppy, duct- tape and bailing wire, spaghetti code jungle.”
- 19. @crichardson Technology stack becomes increasingly obsolete BUT a rewrite is not feasible
- 20. @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
- 21. @crichardson The scale cube X axis - horizontal duplication Z axis -data partitioning Y axis - functional decomposition Scale by splitting sim ilar things Scale by splitting different things
- 22. The microservice architecture is an architectural style that structures an application as a set of services Each microservice is: • highly maintainable and testable • loosely coupled • independently deployable • organized around business capabilities • owned by a small team
- 23. @crichardson Start with one service per team Service Small, autonomous team Split service only to solve a problem e.g. accelerate development and testing
- 24. @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
- 25. @crichardson Benefits of microservices Testability - small service easier/faster to test Deployability - each service is independently deployable Maintainability - small service easier to understand and change Modularity - a service API is impermeable enforces modularity Evolvability - evolve each service’s technology stack independently *Improved scalability and fault tolerance too
- 26. @crichardson Process: Lean + DevOps/Continuous Delivery & Deployment Organization: Small, autonomous, product teams Architecture: microservices Testability Deployability Modularity Modularity Evolvability Maintainability Deliver changes to long-lived applications rapidly, frequently and reliably
- 27. @crichardson Drawbacks of microservices… Complexity Development: IPC, partial failure, distributed data Testing: Integration, end to end, … Deployment …
- 28. @crichardson …Drawbacks of microservices Correctly identifying service boundaries and avoiding the distributed monolith anti-pattern Refactoring a monolithic application to a microservice architecture
- 29. @crichardson Agenda Process Organization Architecture Deliver changes to long- lived applications rapidly, frequently and reliably Success Triangle Scale Cube Hexagonal Architecture API Iceberg services Channel Messaging Unit Integration Component End to End Testing Pyramid
- 30. @crichardson Order Service The traditional 3-tier/layered architecture Presentation Business logic Persistence Order Controller Order OrderDAO Only one? Only one? Depends on persistence?! Doesn’t reflect reality!
- 31. @crichardson The Hexagonal architecture, a.k.a. ports and adapters Order Controller REST- based Proxy Message Subscriber Messages DB adapter, e.g. DAO Business logic HTTP Inbound port, e.g. interface Inbound adapter Outbound port, e.g. interface Outbound adapter HTTP
- 32. @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 DB adapter Business logic
- 33. @crichardson Order Service example Order Service REST API POST /orders Event Publisher Order Created Consumer Service … API Client Restaurant Service Event Subscriber API API Event Publisher Restaurant Created Async
- 34. @crichardson … The structure of a service SLA Telemetry API Telemetry: Metrics, exceptions Externalized configuration Logging Distributed tracing Heath Check endpoint
- 35. @crichardson Agenda Process Organization Architecture Deliver changes to long- lived applications rapidly, frequently and reliably Success Triangle Scale Cube Hexagonal Architecture API Iceberg services Channel Messaging Unit Integration Component End to End Testing Pyramid
- 36. @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()
- 37. 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
- 38. @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
- 39. Design iceberg services Implementation DB API Small, stable API Large, complex implementation Change
- 40. Avoid CRUD service anti- pattern: database wrapper DB API Large, unstable API Minimal implementation
- 41. 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
- 42. @crichardson Agenda Process Organization Architecture Deliver changes to long- lived applications rapidly, frequently and reliably Success Triangle Scale Cube Hexagonal Architecture API Iceberg services Channel Messaging Unit Integration Component End to End Testing Pyramid
- 43. @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
- 44. 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
- 45. @crichardson messaging system Use asynchronous messaging Sender Recipient Message Channel Payload Header http://bit.ly/books-eip
- 46. @crichardson About message channels Abstraction of message broker capabilities, e.g. Apache Kafka topics JMS queues and topics …. Channel types: Point-to-point - deliver to one recipient Publish-subscribe - deliver to all recipients
- 47. @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
- 48. @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
- 49. @crichardson Agenda Process Organization Architecture Deliver changes to long- lived applications rapidly, frequently and reliably Success Triangle Scale Cube Hexagonal Architecture API Iceberg services Channel Messaging Unit Integration Component End to End Testing Pyramid
- 50. @crichardson Microservices enable DevOps DevOps requires automated testing Complexity of microservices requires good automated testing Using the Microservice Architecture without automated testing is self-defeating AND risky http://bit.ly/msa-antipattern-flying-before-walking
- 51. @crichardson The state of automated testing today: Oops! https://cdn.agilitycms.com/sauce-labs/white-papers/sauce-labs-state-of-testing-2018.pdf 😢
- 52. @crichardson The testing pyramid and microservices Unit Integration Includes consumer-driven contract tests Component End to End Classes within service A services adapters An entire service Multiple services or application Brittle, Slow, Costly Reliable, Fast, Cheap
- 53. Pipeline Deployment pipeline: the path from laptop to production Pre commit tests Commit stage Tests Integration Tests Performance Tests Release/ Deploy Other non- functional tests…. Component Tests
- 54. @crichardson Deployment pipeline per service 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
- 55. @crichardson Consumer-driven contract testing Verify that a service (a.k.a. provider) and its clients (a.k.a. consumers) can communicate while testing them in isolation
- 56. @crichardson Contract testing example Api Gateway Order Service Proxy Order Service Order Controller GET /orders/{id} ProviderConsumer
- 57. @crichardson Contract testing example Request from consumer Response from service Describes Written by API Gateway Team API definition by example Order Service Proxy Order Controller GET /orders/{id} ProviderConsumer
- 58. @crichardson Consumer-side contract test OrderService Proxy Order ServiceProxy Tests Use WireMock- based Order Service Test Double Configures Verify that proxy makes requests that match contract and can consume responses “service virtualization” GET /orders/{id}
- 59. @crichardson Provider-side contract test Class BaseHttp { } class HttpTest extends BaseHttp {… Spring Cloud Contract Code generates Reads Configures with mock OrderRepository Order Controller Tests Order Repository Must be consistent Verify API structure matches contracts GET /orders/{id}
- 60. @crichardson Assumption: If consumer and provider are tested independently with the same contracts Consumer and provider can communicate
- 61. @crichardson Application Deployment pipeline End to end tests: a bottleneck and best avoided Order Service deployment pipeline Kitchen Service deployment pipeline Delivery Service deployment pipeline …. End to End tests Production Brittle, Slow, Costly
- 63. @crichardson Testing in production* Challenge: End-to-end testing is brittle, slow, and costly Your end-to-end test environment is a simulation of production No matter how much you test issues will appear in production Therefore: Separate deployment (running in production) from release (available to users) Test deployed code before releasing Automate for fast deployment, rollback and roll forward * a.k.a. Validation in production
- 64. Order Service V1 Order Service V2 Test deployed 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
- 66. @crichardson Summary Process: Lean + DevOps Organization: Small, autonomous teams Microservice Architecture Deliver changes to long- lived applications rapidly, frequently and reliably Success Triangle Scale Cube Hexagonal Architecture API Iceberg services Channel Messaging Unit Integration Component End to End Testing Pyramid Microservice architecture has required -ilities Loose design-time coupling Loose run-time coupling Foundation of modern development The structure of each service The goal