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.

1. 1 | Copyright © 2019
The Truth About the
Service Mesh Data Plane
Christian Posta
@christianposta
Global Field CTO – Solo.io

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 | Copyright © 2019 @christianposta
MY BOOKS
https://bit.ly/istio-in-action
https://www.manning.com/dotd
50% off code:
dotd111819au

4. 4 | Copyright © 2019 @christianposta
HIGHLY RECOMMENDED

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 | Copyright © 20196 | Copyright © 2019
Challenges of adopting a service mesh

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 | 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 | 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 | Copyright © 201910 | Copyright © 2019
Confusion in the data plane

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 | Copyright © 201912 | Copyright © 2019
The truth about the data plane

13. 13 | Copyright © 2019 @christianposta
Service mesh gives a nice API into application networking.

14. 14 | Copyright © 2019 @christianposta
How that API gets implemented will vary.

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 | 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 | 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 | 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 | Copyright © 2019 @christianposta
Sidecar example: Linkerd
Service
Code
Service
Code

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 | Copyright © 2019 @christianposta
Shared gateway example: Istio ingress-gateway

22. 22 | Copyright © 2019 @christianposta
Shared gateway example: Gloo

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 | 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 | 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 | Copyright © 201926 | Copyright © 2019
Things at the data plane heating up!

27. 27 | Copyright © 2019 @christianposta
Data plane getting very interesting…

28. 28 | Copyright © 2019 @christianposta
Data plane getting very interesting…
https://github.com/envoyproxy/envoy-wasm

29. 29 | Copyright © 2019 @christianposta
Now with beta Web Assembly support!
Data plane getting very interesting…
https://gloo.solo.io

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 | Copyright © 2019 @christianposta
What do you do with an API?

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