Linkerd and the Service Mesh
summary
Linkerd migrates from a JVM/Scala/Finagle/Netty proxy that weighs ~150 MB per sidecar to a Kubernetes-first architecture with a Go control plane (~200 MB total) and Rust data plane proxies that run at 10 MB proxy and deliver p99 <1 ms. The rewrite removes plugin middleware and trades some extensibility for zero-config ease of use and much lower overhead; Linkerd1 moves to maintenance while hundreds of clusters run Linkerd2 in production.
AI-written summary · about
chapters (15)
- 0:00Intro
- 2:34What does Linkerd do?
- 3:55What's a service mesh?
- 5:09Service Mesh: The basics
- 7:20Service Mesh: Data Plane
- 8:07Service Mesh: Control Plane
- 8:49Linkerd architecture today (2.x branch)
- 9:27How did we get here?
- 11:54Linkerd 1.x: Built on the "Twitter Stack"
- 13:07Linkerd 1.x: Lessons Learned
- 16:01Rewriting for Linkerd 2.x
- 18:54Why Go for the Control Plane?
- 19:51Why Rust for the Data Plane?
- 21:48Scary Questions in 2017
- 22:50Fast forward to 2019: The Gamble Paid Off!
