Istio, Linkerd 2, or …? S o f t w a r e C i r c u s M e e t u p / M a r c h 2 4 t h 2 0 2 1 A comparison of Service Mesh implementations Jörg Müller @joergm Hanna Prinz @HannaPrinz

• Software Development • DevOps, Kubernetes, Service Mesh Hanna Prinz Consultant 
 at INNOQ Deutschland GmbH [email protected] 
 @HannaPrinz 2

• Architecture, Development, DevOps • Focus on Platform & Infrastructure Jörg Müller Principal Consultant 
 at INNOQ Deutschland GmbH [email protected] 
 @joergm 3

What is a Service Mesh? What problems does it try to solve?

Microservices are distributed Systems Microservice Timeout Retry Routing and Discovery Encryption Microservice Authentication & Authorization Circuit Breaker Metrics Logs 5 @HannaPrinz @joergm @INNOQ

Libraries can help Microservice Microservice Lib Lib 6 @HannaPrinz @joergm @INNOQ

Kubernetes Kubernetes can help as well Microservice Microservice Service 7 @HannaPrinz @joergm @INNOQ

Service Mesh Approach Microservice Proxy Control Plane Metrics Con f ig Microservice Proxy 8 @HannaPrinz @joergm @INNOQ

Service Mesh Architecture Microservice Proxy Control Plane Microservice Proxy Application Data Plane Control Plane Infrastructure Kubernetes API Infrastructure Services 9 @HannaPrinz @joergm @INNOQ

Do you need a service mesh?

Very often the answer is: No. 11 @HannaPrinz @joergm @INNOQ

How many Services? many (>= 10) few only if certain features are dif f icult to realize otherwise 
 (more later) 12 @HannaPrinz @joergm @INNOQ

Diversity of technologies? high low Libraries can be a good alternative 13 @HannaPrinz @joergm @INNOQ

Mostly synchronous communication? yes no Probably a service mesh adds little value 14 @HannaPrinz @joergm @INNOQ

Using Kubernetes? yes no The choice of solutions is signi f icantly reduced 15 @HannaPrinz @joergm @INNOQ

How dynamically do services change? 
 (Versions & Scaling) often rarely Service Meshes probably should not be the focus 16 @HannaPrinz @joergm @INNOQ

Are certain features needed? yes • mTLS • Tracing • Routing • Special Rollouts 17 @HannaPrinz @joergm @INNOQ

Current Implementations

Service Mesh Implementations Istio Open Service Mesh 19 @HannaPrinz @joergm @INNOQ

20 @HannaPrinz @joergm @INNOQ

Choosing an Implementation

In which environment do I want to use the service mesh? 22 @HannaPrinz @joergm @INNOQ

Questions about the environment •What infrastructure do I have in place? •Are there preferred cloud providers? •What knowledge is available? •How f lexible do we want to be? 23 @HannaPrinz @joergm @INNOQ

Kubernetes Kubernetes only Usable without Kubernetes Istio Open Service Mesh 24 @HannaPrinz @joergm @INNOQ

Cloud Provider •The impact is small as long as Kubernetes is used •Many AWS services (especially Fargate/ECS) can be an indicator for AWS App Mesh •Google Cloud has very good Istio support •Microsoft Azure will probably move in the direction of Open Service Mesh (OSM) 25 @HannaPrinz @joergm @INNOQ

Independence through SMI? •"A standard interface for service meshes on Kubernetes“ •Features: • Traf f ic Access Control • Traf f ic Metrics • Traf f ic Specs • Traf f ic Split •De f ines CRDs in Kubernetes that are used by the implementations 26 @HannaPrinz @joergm @INNOQ

Service Mesh Interface Support full partially Istio Open Service Mesh none 27 @HannaPrinz @joergm @INNOQ (unof f icial/3rdparty support)

What features are needed? 28 @HannaPrinz @joergm @INNOQ

Features questions 29 @HannaPrinz @joergm @INNOQ 1. What are the current challenges in the project? 2. Are there must-haves / 
 nice-to-haves? 3. What level of con f igurability is required? 4. What level of effort are we willing to spend?

Differences Between the Meshes Observability Resilience Routing Security 30 @HannaPrinz @joergm @INNOQ

Canary Releasing & A/B Testing percentual split only Istio Open Service Mesh + header- and path-based Service A Service B Canary 90% 10% Service A Service B Canary / /new Header: city=* Header: city=berlin 31 @HannaPrinz @joergm @INNOQ

Differences between the meshes 32 @HannaPrinz @joergm @INNOQ Observability Resilience Routing Security

Resilience Features Microservice Proxy Microservice Proxy Timeout Retry Circuit Breaking x 4s •Many differences in service mesh implementations •Watch out: retry con f ig may apply per service 
 → No extra con f ig of non-idempotent endpoints like HTTP POST! 33 @HannaPrinz @joergm @INNOQ

Chaos Engineering Microservice Proxy Microservice Proxy Fault Injection Delay Injection •Supported in Istio, Kuma and partly Linkerd 2 •With some meshes, an additional deployment is necessary 34 @HannaPrinz @joergm @INNOQ

Differences between the meshes 35 @HannaPrinz @joergm @INNOQ Observability Resilience Routing Security

Differences in Security Features Microservice 1 Proxy Microservice 2 Proxy •All meshes except Trae f ik Mesh support mTLS •Main differences: • mTLS for TCP connections • TLS Enforcement mTLS "Microservice 1 " X 36 @HannaPrinz @joergm @INNOQ mTLS Enforcement

Differences between the meshes 37 @HannaPrinz @joergm @INNOQ Observability Resilience Routing Security

Observability Features •Quality of the dashboard 38 @HannaPrinz @joergm @INNOQ

@HannaPrinz @joergm @INNOQ

@HannaPrinz @joergm @INNOQ

Observability Features •Dashboard quality •Precon f igured Prometheus, Grafana and Jaeger •Tracing support •Access logs (or similar features such as Linkerd 2's "tap") 41 @HannaPrinz @joergm @INNOQ

Is the service mesh subjectively a good f it (production maturity, usability ...)? 42 @HannaPrinz @joergm @INNOQ

Production readiness leaders followers Istio Open Service Mesh new 43 @HannaPrinz @joergm @INNOQ

Con f iguration complexity Microservice 2b Microservice 1 Microservice 2a 10% 90% Example: Traf f ic Split 44 @HannaPrinz @joergm @INNOQ can be one CRD with 10 lines of YAML 
 ... or two CRDs with 30 lines of YAML

Debugging Complexity Microservice Proxy Microservice Proxy Ingress Control Plane Kubernetes & Overlay Network Hardware & Cloud 45 @HannaPrinz @joergm @INNOQ

Performance & Benchmarking •Additional latency: ~ 3ms •Additional CPU & memory resources •Depending on architecture, traf f ic and mesh implementation → Do your own benchmark! 46 @HannaPrinz @joergm @INNOQ

Conclusion

Approaching Service Mesh 0. Is a service mesh the reasonable next step? 
 → is the problem somewhere else? 48 @HannaPrinz @joergm @INNOQ 1. What is the technical environment? 
 → Kubernetes/Cloud/Infrastructure tools 2. What features are needed? 
 → Must-Haves/Nice-to-Haves? 3. Does the service mesh f it subjectively? 
 → Production Readiness, Developer Experience, Con f ig, Performance

More about Service Mesh • Service Mesh Comparison 
 https://servicemesh.es • Blog Post: Happy without a Service Mesh 
 https://www.innoq.com/en/blog/happy-without-a-service- mesh/ • Linkerd Tutorial 
 https://linkerd.io/2/tasks/ • Istio Tutorial 
 https://istio.io/docs/setup/getting-started/ • Sample application with Istio and Linkerd Tutorial on GitHub 
 https://github.com/ewolff/microservice-istio https:// github.com/ewolff/microservice-linkerd GOTO 2020 • Getting started with Service Mesh https://www.youtube.com/watch?v=w14ge2838Vs Service Mesh Primer - 2nd Edition for free at leanpub.com/service-mesh-primer @HannaPrinz @joergm @INNOQ

Krischerstr. 100 40789 Monheim +49 2173 3366-0 Ohlauer Str. 43 
 10999 Berlin 
 Ludwigstr. 180E 
 63067 Offenbach 
 Kreuzstr. 16 
 80331 München 
 Hermannstrasse 13 
 20095 Hamburg 
 Erftstr. 15-17 50672 Köln 
 Königstorgraben 11 90402 Nürnberg innoQ Deutschland GmbH www.innoq.com Thank you! Questions? Hanna Prinz 
 [email protected] 
 @HannaPrinz Jörg Müller [email protected] 
 @joergm Service Mesh Primer - 2nd Edition for free at leanpub.com/service-mesh-primer