Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

YOW! Perth: Cubes, Hexagons, Triangles, and More: Understanding the Microservice Architecture Through Shapes

1,977 views

Published on

YOW! Perth 2019 presentation

The microservice architecture is becoming increasing important. But what is it exactly? Why should you care about microservices? And, what do you need to do to ensure that your organization uses the microservice architecture successfully? In this talk, I’ll answer these and other questions using shapes as visual metaphors. You will learn about the motivations for the microservice architecture and why simply adopting microservices is insufficient. I describe essential characteristics of microservices, You will learn how a successful microservice architecture consist of loosely coupled services with stable APIs that communicate asynchronous. I will cover strategies for effectively testing microservices.

Published in: Software
  • Uterine Fibroids Cure, Discover How To Eliminate Almost, All Uterine Fibroids Within 8 Weeks.. ◆◆◆ http://t.cn/Aig7c6mX
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

YOW! Perth: Cubes, Hexagons, Triangles, and More: Understanding the Microservice Architecture Through Shapes

  1. 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 chris@chrisrichardson.net https://adopt.microservices.io Copyright © 2019. Chris Richardson Consulting, Inc. All rights reserved
  2. 2. @crichardson Presentation goal The essential characteristics of the Microservice Architecture
  3. 3. @crichardson About Chris http://adopt.microservices.io
  4. 4. @crichardson About Chris https://microservices.io/book 40% discount with code ctwyowp19
  5. 5. About Chris: microservices.io Microservices pattern language Articles Example code Microservices Assessment Platform
  6. 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. 7. @crichardson + Marketplace is volatile, uncertain, complex and ambiguous + Businesses must innovate faster Deliver software rapidly, frequently and reliably Software
  8. 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. 9. @crichardson Successful applications often live a very long time Technology changes Need to be able to easily modernize applications +
  10. 10. @crichardson Success Triangle Process Organization Architecture Deliver changes to long-lived applications rapidly, frequently and reliably
  11. 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. 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. 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. 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. 15. -ilities of small monoliths Testability Deployability Maintainability Modularity Evolvability ✅ ✅ ✅ ✅ ✅
  16. 16. @crichardson But successful applications keep growing…. Development Team Application
  17. 17. @crichardson … and growing Development Team A ApplicationDevelopment Team B Development Team C
  18. 18. @crichardson … and modularity breaks down… http://www.laputan.org/mud/ “haphazardly structured, sprawling, sloppy, duct- tape and bailing wire, spaghetti code jungle.”
  19. 19. @crichardson Technology stack becomes increasingly obsolete BUT a rewrite is not feasible
  20. 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. 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. 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. 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. 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. 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. 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. 27. @crichardson Drawbacks of microservices… Complexity Development: IPC, partial failure, distributed data Testing: Integration, end to end, … Deployment …
  28. 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. 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. 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. 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. 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. 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. 34. @crichardson … The structure of a service SLA Telemetry API Telemetry: Metrics, exceptions Externalized configuration Logging Distributed tracing Heath Check endpoint
  35. 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. 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. 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. 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. 39. Design iceberg services Implementation DB API Small, stable API Large, complex implementation Change
  40. 40. Avoid CRUD service anti- pattern: database wrapper DB API Large, unstable API Minimal implementation
  41. 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. 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. 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. 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. 45. @crichardson messaging system Use asynchronous messaging Sender Recipient Message Channel Payload Header http://bit.ly/books-eip
  46. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 56. @crichardson Contract testing example Api Gateway Order Service Proxy Order Service Order Controller GET /orders/{id} ProviderConsumer
  57. 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. 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. 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. 60. @crichardson Assumption: If consumer and provider are tested independently with the same contracts Consumer and provider can communicate
  61. 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
  62. 62. @crichardson https://blogs.msdn.microsoft.com/seliot/2011/04/25/i-dont-always-test- my-code-but-when-i-do-i-do-it-in-production/
  63. 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. 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
  65. 65. @crichardson https://medium.com/@copyconstruct/testing-in-production- the-safe-way-18ca102d0ef1
  66. 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
  67. 67. @crichardson @crichardson chris@chrisrichardson.net http://adopt.microservices.io Questions? 40% discount with code ctwyowp19

×