The document introduces Istio as a solution for managing the complexity of microservices by providing a service mesh that enhances resilience, security, observability, and routing. It discusses drawbacks of traditional approaches and emphasizes moving common concerns to the platform level to improve microservices operations. Istio utilizes sidecar containers (Envoy) to intercept traffic and offer capabilities like dynamic routing, circuit breaking, and chaos engineering, all while remaining transparent to the services themselves.

1. Introduction to Istio Service Mesh
Georgios Andrianakis
Senior Software Engineer - Red Hat

2. We of course need to start talking about
Microservices

3. Microservices are Distributed Systems
They introduce non-trivial complexity into the space
between our microservices - the network

4. Distributed Systems Challenges
● Resilience and fault tolerance
○ Retries
○ Timeouts
○ Circuit Breaker
● Service Discovery
○ Load Balancing
● Observability
○ Logs
○ Metrics
○ Traces
● Security
● Policy Enforcement
● Traffic Shaping
○ Rate Limiting
○ Canary Deployments
○ A/B Testing
○ Fault injection
○ Traffic Shadowing

5. HOW TO DEAL WITH THE
COMPLEXITY?

6. • 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)
Traditional Approach

7. 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
• ......
• @Enable....150 different Things

8. Traditional approach
Spring Cloud
Config Server
Service
Netflix Eureka
Netflix Ribbon Config
Service
Config
Service
Config
Svc Discovery Svc Discovery Svc Discovery
Routing Routing Routing
Netflix Zuul
Server
Circuit Breaker Circuit Breaker Circuit Breaker
Tracing Tracing Tracing
ZipKin Server
INFRASTRUCTURE

9. Drawbacks of this approach
● Need an implementation for each combination of
runtime/framework
○ Might end up forcing specific languages / frameworks on teams
● Need to maintain, upgrade, retire
○ Different teams need to sync to do this correctly
● Classpath / namespace pollution
○ We end up with large deployables even for very small microservices

10. IS THERE A BETTER WAY TO TACKLE
THESE ISSUES?

11. Move horizontal concerns out of the
application and into the platform.
Apply to all services regardless
of implementation
Platform Approach

12. • Individual microservices can better focus on providing
business value
• Allow heterogeneous architectures
• Consistently and correctly enforce approaches to
microservices challenges
Benefits of the Platform Approach

13. MyService
Monitoring
Tracing
API
Discovery
Invocation
Resilience
Pipeline
Authentication
Logging Elasticity
Does vanilla Kubernetes have us
covered?

14. Istio fills in the gaps left open (deliberately)
by Kubernetes
Platform approach

15. HOW IS THIS ACCOMPLISHED?

16. Pod
Container
Sidecar Container
Pod
Container
Service C
Sidecar Container
Pod
Container
Service B
Sidecar Container
The sidecars intercepts all network traffic
Sidecar on Kubernetes
Service A
The sidecar is the secret sauce used to make applications
capable of leveraging the platforms capabilities

17. Pod
Container
Sidecar Container
Pod
Container
Service C
Sidecar Container
Pod
Container
Service B
Sidecar Container
Service A
Envoy is the sidecar used in Istio

18. The proliferation of sidecars
introduces another issue:
How do we reason about a fleet of
these service proxies in a large cluster?

19. A service mesh is decentralized application-
networking infrastructure between your services
that provides resilience, security, observability,
and routing control.
A service mesh is comprised of a data plane
and a control plane.
Enter the Service Mesh

20. Meet Istio
http://istio.io
A control plane for service proxies

21. svcA
Envoy
Pod
Service A
svcB
Envoy
Service B
Control Plane API
Discovery & Config
data to Envoys
Policy
checks,
Telemetry,
Quota,
Rate Limiting
Control flow during
request processing
TLS certs
to Envoy
Traffic is transparently
intercepted and proxied. App is
unaware of Envoy’s presence
Pilot Mixer Citadel
Istio High Level Architecture

22. Let’s compare solutions to Distributed
System challenges
● Traditional Approach
● Istio

23. SERVICE
A
SERVICE
B
CIRCUIT BREAKERS WITHOUT ISTIO
SERVICE
C
CB CB
coupled to the service code

24. POD
SERVICE
A
ENVOY
POD
SERVICE
B
ENVOY
POD
SERVICE
C
ENVOY
CIRCUIT BREAKERS WITH ISTIO
transparent to the services

25. POD
SERVICE
A
ENVOY
POD
SERVICE
B
ENVOY
POD
SERVICE
C
ENVOY
TIMEOUTS AND RETRIES WITH ISTIO
configure timeouts and retries, transparent to the services
timeout: 10 sec
retry: 5
timeout: 15 sec
retry: 5

26. SERVICE
A
SERVICE
B
SECURE COMMUNICATION WITHOUT ISTIO
SERVICE
C
TLS TLS TLS TLS
coupled to the service code

27. SECURE COMMUNICATION WITH ISTIO
POD
SERVICE
A
ENVOY
POD
SERVICE
B
ENVOY
POD
SERVICE
C
ENVOY
mutual TLS authentication, transparent to the services
TLS TLS

28. Gateway
Service
SERVICE
A
SERVICE
B:1
DYNAMIC ROUTING WITHOUT ISTIO
SERVICE
B:2
Netflix Zuul
Server
custom code to enable dynamic routing

29. POD
SERVICE
A
ENVOY
POD
SERVICE
B:v2
ENVOY
CANARY DEPLOYMENT WITH ISTIO
POD
SERVICE
B:v1
ENVOY
User: George
Everyone else

30. POD
SERVICE
A
ENVOY
POD
SERVICE
B:v2
ENVOY
A/B TESTING WITH ISTIO
POD
SERVICE
B:v1
ENVOY
50% traffic
50% traffic

31. POD
SERVICE
A
ENVOY
POD
SERVICE
B:v2
ENVOY
DARK LAUNCHES WITH ISTIO
POD
SERVICE
B:v1
ENVOY
100% traffic
mirror traffic

32. CHAOS ENGINEERING WITHOUT ISTIO
SERVICE
A
SERVICE
B
SERVICE
C
Netflix
Chaos Monkeys
Netflix
Spinnaker
random
termination

33. POD
SERVICE
A
ENVOY
POD
SERVICE
B
ENVOY
POD
SERVICE
C
ENVOY
CHAOS ENGINEERING WITH ISTIO
inject delays, transparent to the services
10 sec delay
in 10% of requests

34. inject protocol-specific errors, transparent to the services
POD
SERVICE
A
ENVOY
POD
SERVICE
B
ENVOY
POD
SERVICE
C
ENVOY
CHAOS ENGINEERING WITH ISTIO
HTTP 500
in 5% of requests

35. SERVICE
A
SERVICE
B
SERVICE
C
DISTRIBUTED TRACING WITHOUT ISTIO
Spring Sleuth
ZipKin
Spring Sleuth
ZipKin
Spring Sleuth
ZipKin
code to enable dynamic tracing

36. POD
SERVICE
A
ENVOY
POD
SERVICE
B
ENVOY
POD
SERVICE
C
ENVOY
DISTRIBUTED TRACING WITH ISTIO & JAEGER
discovers service relationships and process times,
transparent to the services
SERVICE A SERVICE B SERVICE C
210 ms 720 ms
930 ms

37. Time for some eye candy

41. Thank you!
Twitter: @geoand86
Slides: http://slideshare.net/GeorgiosAndrianakis
Further reading
• http://envoyproxy.io
• http://istio.io
• https://medium.com/@mattklein123/
• http://blog.christianposta.com/istio-workshop/slides/
• http://blog.christianposta.com/tags/#istio
• http://bit.ly/istio-tutorial