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.

1

Partager

Télécharger pour lire hors ligne

Microservice & Service Mesh Workshop

Télécharger pour lire hors ligne

Microservice & Service Mesh Workshop

Livres associés

Gratuit avec un essai de 30 jours de Scribd

Tout voir

Microservice & Service Mesh Workshop

  1. 1. Microservices & Service Mesh Workshop Claudio Acquaviva
  2. 2. "All problems in Computer Science can be solved by another level of indirection, except for the problem of too many layers of indirection”. David J. Wheeler, Computer Scientist Inventor of the "Closed Subroutine", 1927-2004.
  3. 3. All information are public. 3 main tasks • Content qualification • Content structuring • Content application
  4. 4. • Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design, Larry Constantine, Ed Yourdon, 1979 • “Low coupling is a sign of a well structured computer system.” (Baixo acoplamento é um sinal de um sistema de computador bem estruturado). • “High cohesion tend to be preferable because it is associated with several desirable traits of software including robustness, reliability, reusability, and understandability.” (Alta coesão tende a ser preferível porque está associada com vários traços de software desejáveis incluindo robutez, confiabilidade, reusabilidade e compreensão) • “...Clearly, cohesion and coupling are interrelated. The greater the cohesion of individual modules in the system, the lower the coupling between modules will be...”. (Claramente, coesão e acoplamente estão inter-relacionados. Quanto maior a coesão dos módulos individuais em um sistema, menor será o acoplamente entre os módulos. Coupling and Cohesion
  5. 5. In summary, Service Orientation is an excellent principle. An ESB implementation approach is not a good solution though. Back in 2005, Anne Thomas Manes, Gartner’s VP, wrote the famous article “SOA is Dead; Long Live Services” (http://apsblog.burtongroup.com/2009/01/soa-is-dead-long-live-services.html). MSA by Adrian Cockcroft, AWS’ VP: “Service-oriented architecture composed of loosely coupled elements that have bounded contexts”. Same principles, distinct implementations. Monoliths -> Microservices Service Orientation – SOA and MSA MicroservicesMonolithDB DB A DB B ESB OrdersCustomers LB Microservice A Customers LB Microservice B Orders LB Microservice C Invoices LB Invoices DB C
  6. 6. • There is no way to build a unified domain model for all systems. • Complex system divided in “Bounded Contexts”. • Each “Context” defines its own unified model and its relationships with other contexts. • A contexto is implemented by a Microservice (or a set of Microservices). DDD – “Domain-Driven Design”
  7. 7. MSA Microservices Architecture API Gateway Legacy Systems Microservices Reference Architecture ERP MDM CRM Mainframe Firewall Firewall DMZ Microservice 1 ... Cloud APIs SaaS PaaS Message Channels Service Component Service Component ... Outer Architecture Inner Architecture Microservice 2 Service Component Service Component Inner Architecture Microservice 3 Service Component Service Component Inner Architecture Microservice N Service Component Service Component Inner Architecture A Guidance Framework for Architecting Portable Cloud and Multicloud Applications, Gartner Eric Knipp, Traverse Clayton, Richard Watson, Gartner, 16/12/16 Identity Provider Mobile Apps End Users 3rd Party Apps
  8. 8. Infraestrutura de Serviços ESB Firewall API Gateway AuthN & AuthZ Service Virtualization & Composition Data Transformation Throttling API Manager Versioning Knowledge Base Life Cycle Management Billing Firewall API Developers Portal AuthN & AuthZ Financials API ConsumersAPI Developers Identity Management AuthN & AuthZ Provisioning Analytics API Publication API Usage Credentials Billing Data TXs Data Service Invocation API Management Reference Architecture MSA API Monitoring API Usage Operational Analytics
  9. 9. Service Provider 1 (SP) Domain B i. e.: On Premises Service Provider 2 (SP) Domain C i. e.: Cloud Identity Provider Principal Identity Provider (IdP) Domain A Credentials (User/Passwd X.509 OTP tokens) Id Token (JWT) • IdP and SPs define a “Circle of Trust”. • OpenID Connect is the preferred standard AuthorizationAuthorizationUser Databases LDAP DBMS
  10. 10. What you have + what you know + what you are Security Factors + + PIN + PIN PIN+ PIN+ What you have + what you are What you have + what you know What you are What you know What you have Authentication Factors Digital Certificate Token OTP Token Personal Identification Number 1 Factor Authentication 2 Factor Authentication 3 Factor Authentication
  11. 11. Communication Models – Synchronous and Asynchronous • Synchronous Calls: • Asynchronous calls can be implemented as 1-to-1 or 1-to-many: API Gateway Service A Service CService B API Gateway Service A Service B HTTP HTTP HTTP HTTP Queue API Gateway Service A Service B HTTP Event Bus Service C
  12. 12. • Microservices are, by definition, a distributed and dynamic environment. • That is, the number of instances of a given Microservice might change overtime. Several reasons: Higher/lower throughput Canary Release A/B testing • How to deal with the policies change problem? Service Registration/Discovery Load Balancing Traffic Control • What about other requirements? Encrypted Communication Service ACL Service Logging Service Tracing Microservice 1 Microservice 2' Microservice 2'' Microservice 2''' Multiple Microservice instances
  13. 13. Microservice 1 (Business Logic) More Logic (non-functional logic) - Service Discovery - Load Balancing - Tracing - Traffic Control - Circuit Breaker - Health Check - Secure Data Transfer Microservice 2 Instances (Business Logic) - Service Discovery - Load Balancing - Tracing - Traffic Control - Circuit Breaker - Health Check - Secure Data Transfer Microservice-to-microservice Communication - Logging - Metrics - Access Control - Logging - Metrics - Access Control More Logic (non-functional logic)
  14. 14. Microservice 1 Standard capabilities - Service Discovery - Load Balancing - Traffic Control - Tracing - Circuit Breaker - Health Check - Secure Data Transfer - Logging - Metrics - Access Control Standard capabilities - Service Discovery - Load Balancing - Traffic Control - Tracing - Circuit Breaker - Health Check - Secure Data Transfer - Logging - Metrics - Access Control Microservice 2 Externalizing Capabilities
  15. 15. ● Tightly-coupled Solution ● Difficult code distribution/upgrade ● It doesn't fit the Microservice polyglot principle Microservice Library - Service Discovery - Load Balancing - Traffic Control - Tracing - Circuit Breaker - Health Check - Secure Data Transfer - Logging - Metrics - Access Control Solution 1 - Library
  16. 16. ● Loosely-coupled Solution ● Microservice code is not impacted by a proxy upgrade ● It doesn't need to follow the Microservice technology implementation decisions (i.e. programming language) ● All the income and outcome traffics are controlled by the proxy Microservice 1 Proxy - Service Discovery - Load Balancing - Traffic Control - Tracing - Circuit Breaker - Health Check - Secure Data Transfer - Logging - Metrics - Access Control Microservice 2 Proxy - Service Discovery - Load Balancing - Traffic Control - Tracing - Circuit Breaker - Health Check - Secure Data Transfer - Logging - Metrics - Access Control Solution 2 - Proxy
  17. 17. Microservice 1 Proxy Microservice 2'Proxy Microservice 2''Proxy Microservice 2'''Proxy Solution – Proxy – Multiple Microservice instances One problem remains: Who is in charge of the proxies configuration?
  18. 18. Microservice 1 Data Plane - Sidecar Data Plane - Sidecar Control Plane Policies Configuration Metrics Data Metrics Data Microservice 2 Service Mesh Pattern
  19. 19. ● Proxies don't do "call-outs": it would be a very big network consuming architecture ● Instead, it's a "push-based" architecture. ● Control Plane ○ Responsible for configuring all the proxies based on policies changes and Microservices instances incarnation/termination ● Data Plane ○ The "runtime" part of the Service Mesh ○ Transparent proxy ○ Stores all the policies defined and pushed by the Control Plane ○ Reports the Control Plane with metrics Service Mesh
  20. 20. • Service Mesh is an “Architecture Pattern” to address the microservice-to-microservice communication requirements. • There are some Service Mesh implementations available today including Istio (http://www.istio.io), Kuma (https://kuma.io/), Linkerd (http://linkerd.io), etc. Sidecar (proxy) Service Mesh Pattern Microservice 1 Business Logic Load Balancing, Service Discovery, Circuit Breaker, Traffic Control, etc Sidecar (proxy) Microservice 2 Business Logic Load Balancing, Service Discovery, Circuit Breaker, Traffci Control, etc Service Mesh Control Plane
  21. 21. ● The network is reliable. ● Latency is zero. ● Bandwidth is infinite. ● The network is secure. ● Topology doesn't change. ● There is one administrator. ● Transport cost is zero. ● The network is homogeneous. • L. Peter Deutsch, one of the original Sun "Fellows", is credited with penning the first seven fallacies in 1994 • Bill Joy and Tom Lyon had already identified the first four as "The Fallacies of Networked Computing” • James Gosling, another Sun Fellow and the inventor of Java, added the eighth fallacy in 1997 Fallacies of Distributed Computing
  22. 22. Service Mesh – Circuit Breaker
  23. 23. Service Mesh – Load Balancing & Service Discovery Microservice 1 Sidecar 1 Registry Service Registration Microservice 2 instances Microservice 2 Sidecar 2 Microservice 2 Sidecar 2 Microservice 2 Sidecar 2 Service Discovery Load Balancing
  24. 24. SidecarMicroservice Sidecar Microservice SidecarMicroservice Sidecar Microservice Control Plane API Gateway ● Coarse-grained policies ● (i.e. Global rate-limiting, User & App Authentication, IP Blacklist, etc.) Service Mesh Identity Provider Users & Apps Requests ● Fine-grained policies ● (i.e. Specific Microservice Cluster rate-limiting) API Management & Service Mesh - Security Revisited
  25. 25. Microservices Architecture Docker EngineDocker Engine API Gateway Firewall Firewall DMZ Docker Engine Outer Architecture Microservice 1 Service Component Service Component Inner Architecture Microservice 1 Service Component Service Component Inner Architecture Microservice 2 Service Component Service Component Inner Architecture Kubernetes Cluster Docker & Kubernetes Identity Provider Mobile Apps End Users 3rd Party Apps
  26. 26. Microservices Architecture Kubernetes PodKubernetes Pod API Gateway Firewall Firewall Mobile Apps End Users 3rd Party Apps DMZ Kubernetes Pod Outer Architecture Microservice 1 Service Component Service Component Inner Architecture Microservice 1 Service Component Service Component Inner Architecture Microservice 2 Service Component Service Component Inner Architecture Message Channels / Message Queues Sidecar 1 Sidecar 1 Sidecar 2 Service Discovery Circuit Breaker Health Checks Traffic Control Service Discovery Circuit Breaker Health Checks Traffic Control Service Discovery Circuit Breaker Health Checks Traffic Control Service Mesh Control Plane The Big Big Picture Kubernetes Cluster Identity Provider
  27. 27. Microservices & Service Mesh Workshop Claudio Acquaviva
  • NimaGhoroubi

    Dec. 5, 2020

Microservice & Service Mesh Workshop

Vues

Nombre de vues

45

Sur Slideshare

0

À partir des intégrations

0

Nombre d'intégrations

0

Actions

Téléchargements

2

Partages

0

Commentaires

0

Mentions J'aime

1

×