Ask Me Anything About Service Mesh
summary
Explains why teams moved from host daemons to sidecars: Linkerd v2 rebuilt off the JVM to be small and fast so thousands of per-pod proxies are practical, enabling mutual TLS per-pod and clearer failure boundaries; warns SMI is a lowest-common-denominator that won’t cover vendor-specific features; points to real tooling like the Solo Autopilot demo and practical limits observed (Google runs up to 11 sidecars in a pod), and calls out missing native Kafka support in Envoy.
AI-written summary · about
chapters (27)
- 0:00Intro
- 1:23What excites you
- 2:19Introductions
- 3:54Two Questions
- 5:35How I look at SMI
- 6:22Is SMI the best
- 8:15Multiple Service Meshes
- 9:50Internal Business Process
- 12:10Node Agents vs Sidecars
- 12:40Why did you switch to Sidecars
- 15:06Network Service Mesh
- 15:40What Service Mesh will evolve into
- 17:29Identity
- 21:02Production Use Cases
- 22:14How Many Sidecars
- 24:20Proxying
- 25:24Queue
- 25:43Transport Security
- 26:22External Services
- 27:26User Experience
- 29:37Operational Overhead
- 31:37API
- 32:22Kubernetes
- 33:21Personas
- 34:34Separation
- 35:39Hiding complexity
- 37:26Patient doesnt need to know
related talks
35mNavigating the Service Mesh Ecosystem
36mPanel: Ask Me Anything: Microservices and Service Mesh [B]
27mService Mess to Service Mesh
37mPanel Discussion: Ask Us Anything: Microservices and Service Mesh
43mWTF Do We Need a Service Mesh?
30mService Mesh Is Still Hard. The Things we all Did Wrong & Tales of Woe
43mService Mesh and the future of networking
11mWelcome & Opening Remarks