The Future of Service Mesh

2 | Copyright © 2022
CHRISTIAN POSTA
VP, Global Field CTO, Solo.io
@christianposta
christian@solo.io

Solo.io - The Next Step in Your Cloud Journey
Well Funded ($135M), $1B Valuation
Satisﬁed Customers (120% Renewals)
Cloud-native Technology Leadership
Cloud-native Education Leadership
The Service Mesh and API Platform
for Kubernetes | Zero-Trust | Microservices

Istio Leadership

Application Networking

What is application networking?
Challenges
● Service discovery
● Load balancing
● Timeouts
● Retry / Budgets
● Circuit breaking
● Tracing, observability
● Secure transport
● Extension

● Example: when svc A calls svc B, svc A should retry up to 3 times, with 0.5s timeouts and total
up to 2.0s timeouts, but should not exceed retry budgets
● Example: when exposing svc A on the network, we should be able to quickly understand which
services call it and restrict callers to only svc B and svc C
● Example: when svc A calls svc B and svc B is failing, try another locality/zone/cluster
● Example: svc A can call svc B 100 times per hour, but if a customer representing a “platinum”
customer, then svc A can call svc B 1000 times per hour
● Example: when svc A calls svc B, and svc B exists in a different line of business, svc A’s
request must be re-authenticated/verified before proceeding
● Example: any untrusted traffic coming into a set of applications must be authenticated and
authorized at call time using potentially different types of auth before allowing to go upstream

Additional
Network Hops
● Typically expensive load
balancers
● More single points of
failure
● Difficult to trace/debug
● Additional expense (cloud
load balancers,
egress/ingress costs, etc)
● Not built for modern,
dynamic, ephemeral
architectures
● Typically overprovisioned,
bloated operational
deployments
● Does not fit into GitOps,
self-serve model
● Lack of isolation
mechanisms (noisy
neighbor problems)
● Central team, use tickets
to coordinate to make
changes
Problems with current approaches
Outdated Technology Doesn’t Scale

Istio - Open Source Service Mesh
2017
Istio Launched
Data Plane
Enhancements
2019-20
7 New Community Releases
1000s Production Users
~ 1000 Community Contributors
2022
CNCF
2019-2022

Top Use Cases and Drivers for
Service Mesh

Business Drivers for Adopting Istio
Observability Resiliency
Security

Network Security in Kubernetes
Default State
!!!
Desired State
“Zero Trust Security”

DIY … Whoops!
81% of companies experienced a certiﬁcate-related outage in the past two years
65% are concerned about the increased workload and risk of outages caused by
shorter SSL/TLS certiﬁcate lifespans.
Human error was a major contributing factor in 95% of breaches

Istio to the Rescue!

Observability - Insights That Drive Competitive Advantage
Building a Uniform Approach
● Understand trafﬁc patterns
● Determine service health
● Anticipate outages
● Detect dangerous activity
● Audit access

Istio - Metrics and Access Logging
[2020-11-25T21:26:18.409Z] "GET /status/418 HTTP/1.1"
418 - via_upstream - "-" 0 135 3 1 "-"
"curl/7.73.0-DEV"
"84961386-6d84-929d-98bd-c5aee93b5c88" "httpbin:8000"
"127.0.0.1:80" inbound|8000|| 127.0.0.1:41854
10.44.1.27:80 10.44.1.23:37652
outbound_.8000_._.httpbin.foo.svc.cluster.local
default
418 - via_upstream - "-" 0 135 3 1 "-"
"curl/7.73.0-DEV"
"127.0.0.1:80" inbound|8000|| 127.0.0.1:41854
10.44.1.27:80 10.44.1.23:37652
default
418 - via_upstream - "-" 0 135 3 1 "-"
"curl/7.73.0-DEV"
"127.0.0.1:80" inbound|8000|| 127.0.0.1:41854
10.44.1.27:80 10.44.1.23:37652
default
metrics

Resiliency - There Will Be Failures
Common Mitigations
● Waiting indeﬁnitely is bad
● Trying again is good
● Degrade gracefully when
services are overwhelmed

Timeouts - Don’t Wait Indefinitely

Retries - Trying Again Is Good
👍

Circuit Breaker - Degrade gracefully when services are overwhelmed

Drive everything through GitOps!

Can this be improved?

Istio Data Plane
https://www.solo.io/blog/ebpf-for-service-mesh/

Istio Data Plane

Introducing Istio Ambient Mesh
A new, open source contribution to the Istio project,
that defines a new sidecar-less data plane.
Improve
Performance
Simplify
Operations
Cost
Reduction
https://istio.io/latest/blog/2022/introducing-ambient-mesh/

How does it work?
● Separate mesh capabilities into L4
and L7
● Adopt only the capabilities you need
● Remove the data plane from the
workload Pods
● Leverage more capabilities in the
CNI
● Reduce attack surface of data plane

How does it work?

Benefits
● No more race conditions between workload
containers and sidecar/init-container, etc
● Don’t need to inject Pods / alter
deployment resources
● Upgrades/patching are out of band /
transparent from the application
● Limited risk profile for opting into mesh
features
● Reduced blast radius of application
vulnerabilities
● Cost savings with reduced data plane
components
● Maintain isolated tenancy, customization,
configuration
● Maintain the foundations of zero-trust
network security
● Improved performance

Demo
(link)
https://bit.ly/ambient-demo-video

VP, Global Field CTO
@christianposta
christian@solo.io
Additional Resources
● https://www.solo.io/events/upcoming/
● https://academy.solo.io
● https://lp.solo.io/white-paper-zero-trust
● https://lp.solo.io/istio-ambient-mesh-explained
● https://istio.io

Manage
APIs
Data
Access
API Gateway | Kubernetes Ingress
Microservices, Security, Observability
Kubernetes CNI, Network Policy
Federation | GraphQL Server

The Future of Service Mesh

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to The Future of Service Mesh

Similar to The Future of Service Mesh (20)

More from All Things Open

More from All Things Open (20)

Recently uploaded

Recently uploaded (20)

The Future of Service Mesh