The Truth About the Service Mesh Data Plane

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

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

MY BOOKS
https://bit.ly/istio-in-action
https://www.manning.com/dotd
50% off code:
dotd111819au

HIGHLY RECOMMENDED

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

• 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:

• 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

• 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!

Confusion in the data plane

• 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!?

The truth about the data plane

Service mesh gives a nice API into application networking.

How that API gets implemented will vary.

Data plane as a spectrum
Implemented
in code
Out of process
sidecar proxy
Shared gateway
per domain
Single centralized
gateway

• 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

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/")
}

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)

Sidecar example: Linkerd
Service
Code
Service
Code

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

Shared gateway example: Istio ingress-gateway

Shared gateway example: Gloo

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

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

• 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

Things at the data plane heating up!

Data plane getting very interesting…

https://github.com/envoyproxy/envoy-wasm

Now with beta Web Assembly support!
https://gloo.solo.io

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

What do you do with an API?

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

The Truth About the Service Mesh Data Plane

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to The Truth About the Service Mesh Data Plane

Similar to The Truth About the Service Mesh Data Plane (20)

More from Christian Posta

More from Christian Posta (20)

Recently uploaded

Recently uploaded (20)

The Truth About the Service Mesh Data Plane