Why Sidecars? Moving the Stack out of the Monolith
summary
Argues that the useful claim is concrete: extract common infrastructure into sidecars so functionality is reusable, localized to the host and isolated per instance. Gives concrete tools and patterns: prana, HTTP reverse proxies like nginx, service meshes like linkerd and envoy, OAuth2 and Let's Encrypt sidecars. Describes a config sidecar that writes files to disk, avoids library rebuilds, scales to tens of thousands of copies, and reduces blast radius — real components that are built and proven in production.
AI-written summary · about
chapters (15)
- 0:00Intro
- 0:32But first, let's talk about me.
- 1:54Sidecars extend and enhance the main container.
- 2:21Trigger Warning
- 2:49MONOLITHS ARE TERRIBLE
- 3:01Choose Your Own Architecture
- 4:32CONGRATULATIONS! You live!
- 8:38SIDECARS!
- 11:15But shared libraries provide reuse.
- 13:06Good testing and Clearly defined interfaces
- 18:16How is this different?
- 20:39If you had used a sidecar.
- 21:13Locality and Isolation
- 22:24Reuse Locality Isolation
- 26:18Linkerd: service-to-service routing in a sidecar.
related talks
21mA Lightweight gRPC-Compatible Implementation for Sidecars
38mAsk Me Anything About Service Mesh
01h 07mImplementing Sidecars Microservice Pattern using Envoy Proxy
30mAdding Sidecars to Cloud Foundry - Gabriel Rosenhouse & Angela Chin
20mHow to Optimise your Mesh with Istio Sidecar
27mOperationalizing Kubernetes Sidecars in Production at Salesforce
26mBreaking vendor lock-in with Cloud Sidecar
19mMultigrain Services