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.

Role of Integration and Service Mesh in Cloud Native Architecture KubeCon 2108

78 views

Published on

Building useful services across our collection of existing applications, microservices, and now functions, we see a common theme: services must be able to communicate with each other, and solve problems like data mediation, routing, policy enforcement, security, and others. Service mesh is a technology that has emerged in container-based environments to help solve some of these problems; however, not all of them can be solved by pushing the problems to a different abstraction. Understanding the role and responsibility of service mesh and application-integration frameworks can help you successfully build useful business services on a cloud native platform. This talk will help you understand those roles and responsibilities and how service mesh and application integration co-exist to build cloud native applications.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Role of Integration and Service Mesh in Cloud Native Architecture KubeCon 2108

  1. 1. Role of Integration and Service Mesh in Cloud-Native Architecture @christianposta
  2. 2. Christian Posta Chief Architect, cloud application development Twitter: @christianposta Blog: http://blog.christianposta.com Email: christian@redhat.com Slides: http://slideshare.net/ceposta •  Author “Microservices for Java developers” and “Introducing Istio Service Mesh” •  Committer/contributor lots of open-source projects •  Blogger, speaker, mentor, leader
  3. 3. https://www.manning.com/books/istio-in-action
  4. 4. @christianposta Innovation is admitting we don’t have all the answers Mark Schwartz – Former CIO USCIS
  5. 5. @christianposta https://puppet.com/resources/whitepaper/state-of-devops-report
  6. 6. @christianposta Application safety and correctness in a distributed system is the responsibility of the application teams.
  7. 7. @christianposta The end-to-end principle: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.)
  8. 8. @christianposta
  9. 9. TCP adds reliable communication @christianposta
  10. 10. As we move to services architectures, we push the complexity to the space between our services. @christianposta
  11. 11. @christianposta
  12. 12. @christianposta
  13. 13. @christianposta
  14. 14. @christianposta
  15. 15. •  Orchestrate calls across multiple microservices •  Aggregate, combine, transform, split, on “messages” •  Deal with atomicity / consistency issues •  Message idempotency / message de-dupe •  DDD anti-corruption layers / adapters / transformation •  Tie in with existing “backend systems” •  Dynamic, responsive, programmable routing Application integration (done in the app) @christianposta
  16. 16. •  Service discovery •  Retries •  Timeouts •  Load balancing •  Rate limiting •  Thread bulk heading •  Circuit breaking @christianposta Application networking (in the app? outside?)
  17. 17. Application networking (controlled deployment) •  Edge/DMZ routing •  Surgical / fine / per-request routing •  A/B rollout •  Traffic shaping •  Internal releases / dark launches •  Request shadowing •  Fault injection @christianposta
  18. 18. •  adaptive, zone-aware •  Deadlines •  Health checking •  Stats, metric, collection •  Logging •  Distributed tracing •  Security @christianposta Application networking (observability)
  19. 19. •  Netflix Hystrix (circuit breaking / bulk heading) •  Netflix Zuul (edge router) •  Netflix Ribbon (client-side service discovery / load balance) •  Netflix Eureka (service discovery registry) •  Brave / Zipkin (tracing) •  Netflix spectator / atlas (metrics) “Microservices” patterns @christianposta
  20. 20. http://bit.ly/application-networking@christianposta
  21. 21. But I’m using Spring! •  spring-cloud-netflix-hystrix •  spring-cloud-netflix-zuul •  spring-cloud-netflix-eureka-client •  spring-cloud-netflix-ribbon •  spring-cloud-netflix-atlas •  spring-cloud-netflix-spectator •  spring-cloud-netflix-hystrix-stream •  ….. •  ...... •  @Enable....150differentThings
  22. 22. But I’m using Vert.x! •  vertx-circuit-breaker •  vertx-service-discovery •  vertx-dropwizard-metrics •  vertx-zipkin? •  ….. •  ...... @christianposta
  23. 23. Screw Java - I’m using NodeJS! JavaScript is for rookies, I use Go! But python is so pretty! I prefer unreadability… Perl for me! @christianposta
  24. 24. •  Require specific language to bring in new services •  A single language doesn’t fit for all use cases •  How do you patch/upgrade/manage lifecycle? •  Need strict control over application library choices •  Inconsistent implementations •  Incorrect implementations Some drawbacks to this approach? @christianposta
  25. 25. In practice, operability of our services becomes a top priority very fast @christianposta
  26. 26. Let’s optimize for operability @christianposta
  27. 27. Meet Envoy Proxy http://envoyproxy.io
  28. 28. Envoy is… •  service proxy •  written in C++, highly parallel, non-blocking •  L3/4 network filter •  out of the box L7 filters •  HTTP 2, including gRPC •  baked in service discovery/health checking •  advanced load balancing •  stats, metrics, tracing •  dynamic configuration through xDS
  29. 29. Envoy implements •  zone aware, least request load balancing •  circuit breaking •  outlier detection •  retries, retry policies •  timeout (including budgets) •  traffic shadowing •  rate limiting •  access logging, statistics collection •  Many other features!
  30. 30. @christianposta
  31. 31. As a service-instance proxy @christianposta
  32. 32. Service instance proxy AKA Sidecar @christianposta
  33. 33. A service mesh is a distributed application infrastructure that is responsible for handling network trafIic on behalf of the application in a transparent, out of process manner. A service mesh helps to solve problems related to resiliency, security, observability, and routing control. @christianposta Time for deIinitions:
  34. 34. Service mesh technologies typically provide: •  Service discovery / Load balancing •  Secure service-to-service communication •  Traffic control / shaping / shifting •  Policy / Intention based access control •  Traffic metric collection •  Service resilience @christianposta
  35. 35. Meet Istio.io http://istio.io A control plane for service proxies
  36. 36. What higher-order clusters semantics does Istio enable? •  Request-level control •  Graduated deployment and release •  Service observability •  Cluster reliability •  Chaos testing •  Policy enforcement
  37. 37. Resilience with timeouts, retries, budgets, circuit breakers, service discovery, etc @christianposta
  38. 38. Zone aware, sophisticated client-side load balancing @christianposta
  39. 39. Fine-grained trafIic control and routing @christianposta
  40. 40. http://bit.ly/application-networking TrafIic shadowing @christianposta
  41. 41. Secure transport with mTLS @christianposta
  42. 42. Metrics, logs, distributed tracing out of the box http://bit.ly/application-networking
  43. 43. Istio and service mesh don’t allow you to offload responsibility to the infrastructure; they just add some level of reliability and optimize for operability @christianposta
  44. 44. Demo! http://bit.ly/istio-tutorial
  45. 45. Thanks! BTW: Hand drawn diagrams made with Paper by FiftyThree.com ☺ Twitter: @christianposta Blog: http://blog.christianposta.com Email: christian@redhat.com Slides: http://slideshare.net/cepostaFollow up links: •  http://launch.openshift.io •  http://istio.io •  http://envoyproxy.io •  http://developers.redhat.com/blog •  http://blog.christianposta.com/istio-workshop/slides/ •  http://blog.openshift.com •  https://www.redhat.com/en/open-innovation-labs

×