Service Mesh Journey - Building Security and Reliability One Si...
summary
Confluent Cloud runs Istio in its control plane to secure and route traffic for millions of requests per second across tens of thousands of Kubernetes clusters and Kafka clusters, adopting Istio incrementally to avoid rewiring apps. The platform implements mTLS and SPIRE for uniform workload identity, adds OpenTelemetry for observability, and uses multicluster TLS passthrough to preserve identity. Migration estimates drop from ~12.5 engineer‑years to ~2.5 engineers and an estimated $3–5M savings. Operational hiccups (SPIRE agent socket, SDS fallback) get fixed via Istio options, CSI driver and moving toward ambient/Ztunnel.
AI-written summary · about
chapters (13)
- 0:00Confluence’s service mesh journey
- 1:09Reasons for adopting mesh
- 3:55ROI for zero trust
- 7:27Compliance and FIPS
- 8:09Workload identity with SPIRE/SPIFFY
- 10:17SPIRE at enterprise scale
- 12:00Multicluster identity propagation
- 14:10Early adoption fixes
- 16:58Operational challenges
- 17:41Ambient mode and sidecarless mesh
- 19:29Ambient performance benefits
- 20:11Future plans for ambient
- 20:57Q&A on SPIRE/SPIFFY
related talks
40mReimagining Application Networking and Security
32mIstio: Sailing to a Secure Services Mesh
32mIstio: Weaving the Service Mesh [I]
44mService Mesh - The New Single Point of Failure
28mRed Light, Green Light: Traffic Security in the Service Mesh with Istio
48mIstio An open platform to connect, manage, and secure microservices
30mService Mesh Is Still Hard. The Things we all Did Wrong & Tales of Woe
10mService Mesh Security in a Nutshell