Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

The Truth About the Service Mesh Data Plane

1.066 Aufrufe

Veröffentlicht am

The exploration of service mesh for any organization comes with some serious questions. What data plane should I use? How does this tie in with my existing API infrastructure? What kind of overhead do sidecar proxies demand? As I've seen in my work with various organizations over the years "if you have a successful microservices deployment, then you have a service mesh whether it’s explicitly optimized as one or not."

In this talk, we seek to understand the role of the data plane and how to pick the right component for the problem context. We start off by establishing the spectrum of data-plane components from shared gateways to in-code libraries with service proxies being along that spectrum. We clearly identify which scenarios would benefit from which part of the data-plane spectrum and show how modern service meshes including Istio, Linkerd, and Consul enable these optimizations.

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

The Truth About the Service Mesh Data Plane

  1. 1. 1 | Copyright © 2019 The Truth About the Service Mesh Data Plane Christian Posta @christianposta Global Field CTO – Solo.io
  2. 2. 2 | Copyright © 2019 @christianposta CHRISTIAN POSTA • Field CTO @ Solo.io • Author of a few books • Contributor to many open-source projects • Architect, blogger, speaker, mentor, leader @christianposta christian@solo.io https://blog.christianposta.com https://slideshare.net/ceposta
  3. 3. 3 | Copyright © 2019 @christianposta MY BOOKS https://bit.ly/istio-in-action https://www.manning.com/dotd 50% off code: dotd111819au
  4. 4. 4 | Copyright © 2019 @christianposta HIGHLY RECOMMENDED
  5. 5. 5 | Copyright © 2019 The Service Mesh Journey with Solo.io Solo.io connects and manages the world’s applications with APIs and service mesh across any infrastructure. Announcements coming today 
  6. 6. 6 | Copyright © 20196 | Copyright © 2019 Challenges of adopting a service mesh
  7. 7. 7 | Copyright © 2019 @christianposta • Do you have a mix of application languages or frameworks? • Large deployment of microservices on cloud infrastructure? • Struggling to implement application interaction observability? • Have you mastered your existing infrastructure stack? Do you need a service mesh? https://speakerdeck.com/thockin/weve-made-quite-a-mesh Check out talk from @thockin:
  8. 8. 8 | Copyright © 2019 @christianposta • Which one to choose? • Who's going to support it? • Multi-tenancy issues within a single cluster? • No good way to manage multiple clusters? • Fitting with existing services (sidecar lifecycle, race conditions, etc) • What's the delineation between developers and operations? • Non container environments / hybrid env? • Centralization vs decentralization Challenges of adoption
  9. 9. 9 | Copyright © 2019 @christianposta • Start at the edge • Start with one proxy, grow to more • Pick a subset of traffic/applications • Get demonstrable value from it • Continue with measurable iterations • Data plane matters! A sensible way to start with service mesh: learn your data plane!
  10. 10. 10 | Copyright © 201910 | Copyright © 2019 Confusion in the data plane
  11. 11. 11 | Copyright © 2019 @christianposta • API Gateway vs service mesh? • North/south vs east/west • Sidecar vs shared proxy? • Envoy vs nginx vs linkerd proxy vs others? • What needs to go into my code? What do I pick? They seem to overlap!?
  12. 12. 12 | Copyright © 201912 | Copyright © 2019 The truth about the data plane
  13. 13. 13 | Copyright © 2019 @christianposta Service mesh gives a nice API into application networking.
  14. 14. 14 | Copyright © 2019 @christianposta How that API gets implemented will vary.
  15. 15. 15 | Copyright © 2019 @christianposta Data plane as a spectrum Implemented in code Out of process sidecar proxy Shared gateway per domain Single centralized gateway
  16. 16. 16 | Copyright © 2019 @christianposta • Performance is paramount, cannot use sidecar proxy • Need fine-grained circuit breaking or other resilience measures • More complicated load balancing involving business logic • Cannot deploy a sidecar Implemented as code When to do Watch out for: • Tightly intertwined with your application • Can be difficult to change • Trying to maintain multiple language implementations
  17. 17. 17 | Copyright © 2019 @christianposta Implemented as code: example, Consul Service Mesh func main() { client, _ := api.NewClient(api.DefaultConfig()) svc, _ := connect.NewService("my-service", client) defer svc.Close() // Get an HTTP client httpClient := svc.HTTPClient() // Perform a request, then use the standard response resp, _ := httpClient.Get("https://userinfo.service.consul/") }
  18. 18. 18 | Copyright © 2019 @christianposta Implemented as “sidecar” proxy • Cannot modify applications • Have multiple languages/frameworks • Overhead is minimal relative to the app • Need a high level of decentralization When to do Watch out for: • Not understanding underlying proxy technology • Race conditions when starting alongside app • Updating when making changes • Leaking proxy-specific information (ie, headers, etc)
  19. 19. 19 | Copyright © 2019 @christianposta Sidecar example: Linkerd Service Code Service Code
  20. 20. 20 | Copyright © 2019 @christianposta Implemented as shared domain gateway • Cannot use or not ready for sidecar • Provide a single entry point for group of related services • Enforce boundaries • Decoupling of API When to do Watch out for: • Extra hops • Insecure communication last mile • Noisy neighbor
  21. 21. 21 | Copyright © 2019 @christianposta Shared gateway example: Istio ingress-gateway
  22. 22. 22 | Copyright © 2019 @christianposta Shared gateway example: Gloo
  23. 23. 23 | Copyright © 2019 @christianposta Implemented as central gateway • When just starting out • Expect a single central point of ingress/egress • Operational complexity of other approaches too high for current situation When to do Watch out for: • Workflow bottleneck • Insecure communication last mile • Noisy neighbor
  24. 24. 24 | Copyright © 2019 @christianposta Implemented in code Out of process sidecar proxy Shared gateway per domain Single centralized gateway Data plane API CNCF Working Group: Unified Data Plane API
  25. 25. 25 | Copyright © 2019 @christianposta • Universal, cross-client/server data plane management API • CNCF governed working group; UDPA-WG • Mailing list: udpa-wg@lists.cncf.io • Charter and future development work: https://github.com/cncf/udpa • Development work Q1-Q3 2020, intercept the Envoy v4 xDS API EOY 2020 Universal Data Plane API
  26. 26. 26 | Copyright © 201926 | Copyright © 2019 Things at the data plane heating up!
  27. 27. 27 | Copyright © 2019 @christianposta Data plane getting very interesting…
  28. 28. 28 | Copyright © 2019 @christianposta Data plane getting very interesting… https://github.com/envoyproxy/envoy-wasm
  29. 29. 29 | Copyright © 2019 @christianposta Now with beta Web Assembly support! Data plane getting very interesting… https://gloo.solo.io
  30. 30. 30 | Copyright © 2019 @christianposta The service mesh API matters! Implemented in code Out of process sidecar proxy Shared gateway per domain Single shared gateway Control plane API API API API API
  31. 31. 31 | Copyright © 2019 @christianposta What do you do with an API?
  32. 32. 32 | Copyright © 2019 Check out our booth for multi-cluster service mesh management demo. Idit Levine’s talk today at 2:20p My KubeCon workshop: “Service mesh for the developer workflow” Thursday 2:25p

×