Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

SVCC Microservices: Decomposing Applications for Testability and Deployability

877 vues

Publié le

Successful applications have a habit of growing. What’s more, the rate of growth increases over time because the development team typically gets larger. Eventually, the application will become extremely large and the organization ends up in monolithic hell. All aspects of development, testing and deployment are slow and painful. It’s impossible for the developers to keep up with the demands of the business. And, to make matters worse the application uses a technology stack that is increasingly obsolete. The way to escape monolithic hell is to migrate to the microservice architecture.

In this talk, you will learn about the essential characteristics of microservices. I describe the benefits and drawbacks of the microservice architecture and when it makes sense to use it. You will learn about the design problems you will encounter when using microservices. I describe how to solve this problems by applying the microservices pattern language. You will learn how the microservice architecture accelerates the delivery of large, complex applications.

Given at Silicon Valley Code Camp 2018

Publié dans : Logiciels
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

SVCC Microservices: Decomposing Applications for Testability and Deployability

  1. 1. @crichardson Microservices: decomposing applications for testability and deployability 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://learn.microservices.io Copyright © 2018. Chris Richardson Consulting, Inc. All rights reserved
  2. 2. @crichardson Presentation goal Overview of the Microservice architecture Benefits and drawbacks
  3. 3. @crichardson About Chris
  4. 4. @crichardson About Chris Microservices training and consulting (http://www.chrisrichardson.net/)
  5. 5. @crichardson About Chris Founder of a startup that is creating an open-source/SaaS platform that simplifies the development of transactional microservices (http://eventuate.io)
  6. 6. @crichardson About Chris https://www.manning.com/books/microservices-patterns 40% discount with code ctwsvcc18
  7. 7. About Chris: microservices.io Microservices pattern language Articles Code examples Microservices Assessment Platform - coming soon
  8. 8. @crichardson Agenda From monolith to microservices Microservices != silver bullet The Microservices pattern language
  9. 9. @crichardson Let’s imagine that you are building a cool new food delivery application….
  10. 10. @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
  11. 11. @crichardson The monolithic architecture is NOT an anti-pattern
  12. 12. @crichardson But successful applications keep growing…. FTGO Team FTGO Application
  13. 13. @crichardson … and growing Order Team FTGO ApplicationKitchen Team Delivery Team
  14. 14. @crichardson Eventually: Testing and deployment is slow and painful Rapid, frequent and reliable delivery is impossible
  15. 15. @crichardson Technology stack becomes increasingly obsolete BUT A rewrite is not feasible
  16. 16. @crichardson Monolithic hell By John Martin, Public Domain, https://commons.wikimedia.org/w/index.php?curid=3353638
  17. 17. @crichardson Businesses must innovate faster Software Deliver software rapidly, frequently and reliably
  18. 18. @crichardson FTGO Application Monolithic Architecture Order Service Kitchen Service Delivery Service … Service Microservice Architecture FTGO Application Loosely coupled Developed, tested, deployed, independently
  19. 19. @crichardson Application Business capability Service Food to Go Order Taking Kitchen management Delivery management Business Capability = something a business does to deliver value … Order Service Kitchen Service Delivery Service … Service
  20. 20. @crichardson Browser Mobile Device Content Router API Gateway Order Service Kitchen Service Delivery Service … Service Order Database Kitchen Database Delivery Database … Database HTTP /HTML REST REST Orders web application Kitchen Web application …. Inbound Notification Gateway Notifications
  21. 21. @crichardson Service = independently deployable component Command Query API Event Publisher Event Subscriber API Client Consumer facing Implementation Synchronous: REST, gRPC, … Asynchronous: Command/Reply, Notification Service database Events Events Synchronous: REST, gRPC, … Asynchronous: Command/Reply, Notification Data owned by the service Data replicated from elsewhere SLA
  22. 22. Service size is secondary microservice architecture
  23. 23. @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
  24. 24. @crichardson Modern software development: moving fast and not breaking things! 46x 440x 24x 5x lower Amazon: ~0.001% Netflix: 16 minutes Amazon: every 11.6 seconds
  25. 25. @crichardson Deliver software rapidly, frequently and reliably Process: DevOps/Continuous Delivery & Deployment Organization: Small, autonomous teams Architecture: microservices Testability Deployability Enables Autonomy
  26. 26. @crichardson Enables organization to scale without impacting productivity
  27. 27. @crichardson Microservices experiment safely and evolve the technology stack Java Java Java Java Java Golang “GoLang is cool!” Java Kotlin Java Java “Kotlin is better!” Java Kotlin
  28. 28. @crichardson Agenda From monolith to microservices Microservices != silver bullet The Microservices pattern language
  29. 29. @crichardson No silver bullets http://en.wikipedia.org/wiki/Fred_Brooks
  30. 30. @crichardson Drawbacks of microservices Complexity Development: IPC, partial failure, distributed data Testing: Integration, end to end, … Deployment …
  31. 31. @crichardson Are microservices a good fit for my application?
  32. 32. @crichardson Do I have the skills/pre-requisites in place: automated testing automated provisioning ….. ?
  33. 33. @crichardson When using microservices: How to decompose an application into services? How to deploy an application’s services? How to handle cross cutting concerns? Which communication mechanisms to use? How do external clients communicate with the services? How does a client discover the network location of a service instance? How to prevent a network or service failure from cascading to other services? How to maintain data consistency and implement queries? How to make testing easier? How to understand the behavior of an application and troubleshoot problems? How to implement a UI screen or page that displays data from multiple services?
  34. 34. @crichardson Agenda From monolith to microservices Microservices != silver bullet The Microservices pattern language
  35. 35. @crichardson Microservice pattern language = collection of patterns that solve these architecture, design, development and operational problems
  36. 36. @crichardson What’s a pattern? Reusable solution to a problem occurring in a particular context
  37. 37. @crichardson The structure of a pattern encourages objectivity
  38. 38. @crichardson Without patterns My favorite technology rocks Your favorite technology sucks http://nealford.com/memeagora/2009/08/05/suck-rock-dichotomy.html
  39. 39. @crichardson With patterns: Pattern Benefits Drawbacks Issues Alternative Patterns Patterns that address issues
  40. 40. @crichardson Microservices pattern language: http://microservices.io Splitting Reassembling Operations Architecture Microservice patterns Data patterns Communication patterns Application architecture Cross-cutting concerns Security Deployment Maintaining data consistency External API Reliability Discovery Transactional messaging Testing Observability UI Decomposition Database architecture Querying Communication style API gateway Client-side discovery Server-side discovery Service registry Self registration 3rd party registration Multiple Services per host Single Service per Host Service-per- Container Service-per-VM Messaging Remote Procedure Invocation Database per Service Saga Shared database Microservice Chassis Backend for front end Event sourcing Aggregate Monolithic architecture Microservice architecture Motivating Pattern Solution Pattern Solution A Solution B General Specific Serverless deployment Circuit BreakerAccess Token Domain-specific Externalized configuration Consumer-driven contract test Service Component Test Exception tracking Distributed tracing Audit logging Application metrics Log aggregation Health check API Service deployment platform Server-side page fragment composition Client-side UI composition Decompose by business capability Decompose by subdomain CQRS Transaction log tailing Transactional Outbox Polling publisher API Composition Domain event Consumer-side contract test Sidecar Service mesh Application patterns Infrastructure patterns Application Infrastructure patterns Log deployments and changes
  41. 41. @crichardson The pattern language guides you when developing an architecture What architectural decisions you must make For each decision: Available options Trade-offs of each option
  42. 42. @crichardson Key patterns
  43. 43. Issue: What’s the deployment architecture? Forces Maintainability Deployability Testability … Monolithic architecture Microservice architecture Single deployable/ executable OR Tightly coupled services Multiple loosely coupled services
  44. 44. Issue: How to decompose an application into services? Forces Stability Cohesive Loosely coupled Not too large Decompose by business capability Decompose by subdomain Organize around business capabilities Organize around DDD subdomains
  45. 45. @crichardson Issue: how to maintain data consistency? Context • Each service has its own database • Data is private to a service Forces Transactional data consistency must be maintained across multiple services 2PC is not an option
  46. 46. @crichardson Issue: how to perform queries? CQRS Context Each service has its own database Forces Queries must join data from multiple services Data is private to a service Maintain query views by subscribing to events API Composition
  47. 47. @crichardson Issue: what external API to expose? Context One or more clients access the application’s API Forces Different clients need different data Different clients use different networks Mismatch between client’s needs and fine-grained service APIs Application architecture must evolve without impacting clients Services might use protocols that are not web friendly API gateway Backend for front end
  48. 48. @crichardson Issue: how to test that services collaborate? Context Application consists of multiple collaborating services Forces Services collaborate and must agree on APIs End-to-end tests are slow, brittle, and expensive and best avoided Client Service Contract defines Consumer- side contract test Tests Uses Consumer- driven contract test Tests Uses
  49. 49. @crichardson The rest are generic technical architecture patterns = Undifferentiated heavy lifting!
  50. 50. @crichardson Issue: How do services communicate? Messaging Remote Procedure Invocation Domain-specific Forces Services must communicate Usually processes on different machines …
  51. 51. @crichardson Issue: How to handle cross cutting concerns? Microservice Chassis Forces Every service must implement logging; externalize configuration; health check endpoint; metrics; …
  52. 52. Issue: How to deploy an application’s services? Multiple Services per host Single Service per Host Service-per- Container Service-per-VM Serverless deployment Service deployment platform Forces Multiple languages Isolated Constrained Monitor-able Reliable Efficient
  53. 53. @crichardson Issue: How to discover a service instance’s network location? Client-side discovery Server-side discovery Service registry Self registration 3rd party registration Forces Client needs IP address of service instance Dynamic IP addresses Dynamically provisioned instances
  54. 54. @crichardson Issue: how to monitor the behavior of your application? Exception tracking Distributed tracing Audit logging Application metrics Log aggregation Health check API
  55. 55. @crichardson Summary The goal of architecture is to satisfy non-functional requirements: deployability, testability, … To enable DevOps/continuous delivery/deployment use the appropriate architectural style Small applications Monolithic architecture Complex applications Microservice architecture Use the pattern language to guide your decision making
  56. 56. @crichardson @crichardson chris@chrisrichardson.net http://learn.microservices.io Questions? 40% discount with code ctwsvcc18

×