The Service Mesh: Past, Present, and Future [B]
summary
Service mesh is presented as a separate runtime layer that moves retries, timeouts, TLS and circuit-breaking out of apps into a pair of proxies per hop, giving consistent visibility (success rate, latency, volume) and centralized policy. Examples compare Istio and Envoy and focus on Linkerd production use and a new Kubernetes-first Conduit design with a Rust data plane and Go control plane, aiming for tiny sidecars, predictable p99 latency, and per-service identity; Conduit is launched and early users report it works for lightweight k8s workloads.
AI-written summary · about
chapters (26)
- 0:00Intro
- 2:50Resilience
- 3:46Stress
- 4:35Software Engineering
- 5:07Reliability
- 5:50Cloud Native
- 6:30Whats changed
- 7:25Runtime Communication
- 8:05Twitter Architecture
- 8:50Microservices
- 11:05Whats missing
- 12:20What is a Service Mesh
- 12:42The LAMP Stack
- 13:22Fad Clients
- 15:50Reliability Visibility
- 17:22The Future
- 18:30Performance
- 19:16Operability
- 20:39Separation of Concerns
- 21:03Conduit
- 26:41Thrift
- 28:19What happens when Kubernetes is replaced
- 29:20Is conduit a data plane or control plane
- 30:54How does conduit compare to Envoy
- 32:06Security implications
- 35:14Preliminary integration
related talks
38mThe Untapped Power of Services - L7 Load Balancing Without a Service Mesh
36mService Mesh Is on the Way to Witness the...
36mCheops - Can a "service mesh" be the right solution for the Edge?
11mLightning Talk: Domain-Oriented Microservice Architecture with Kuma
49mGraphQL Meshes
09mLightning Talk: Where Has My Circuit Breaker Gone?
01h 19mGraphQL Mesh - A Federated Gateway for Any API Protocol - GraphQL, OpenAPI, gRPC and More
28mPractical Microservices, Practical Whiskey