How Google Manages Sidecars for Millions of Containers Without Breaking Anything (Much
summary
Google replaces per-language client stacks by rolling a C++ sidecar to millions of processes, finishing a global rollout over about 18 months. Updates use a dev/stable release cadence (weekly dev, monthly stable), autopilot versus bound modes, restart-based deployments, per-team quick rollback buttons, and heavy performance work so CPU and latency stay tiny. Early experiments with shared memory failed and the system switches to domain sockets. A zero-day fix rolls out in days to a week without breaking user services.
AI-written summary · about
chapters (12)
- 0:00Introduction to sidecars
- 0:38Why Google adopted sidecars
- 3:23Overcoming operational challenges
- 6:18Phased rollout strategy
- 8:07Performance and communication
- 10:43Managing the rollout pace
- 11:41Upgrading and versioning
- 13:56Rollback procedures
- 16:02Debugging and lessons learned
- 18:54Avoiding over-complication
- 22:36Conclusion and results
- 23:42Q&A session
related talks
43mCloud Native - effective computing at scale
43mContainers Change Everything
11mAbstracting infrastructure away from developers
51mKubernetes: Changing the Way That we Think and Talk About Computing
30mBuilding distributed systems is hard - case study (...)
57mDebugging Java in Production on Google Cloud Platform
20mCollision 2015 - Urs Holzle of Google with Bruce Upbin of Forbes
46mOk, so I have all these Containers, what now?
