The Mechanics of Deploying Envoy at Lyft
summary
Envoy gets rolled out incrementally: first as an edge proxy, then co‑located with every service until Lyft reaches 100% coverage across hundreds of services, eliminating MongoDB connection death spirals so outages stop. Service discovery uses a simple 200-line Python cron job writing to DynamoDB, not ZooKeeper, and configs are machine‑generated with Jinja and per‑host manifests; control APIs (CDS/RDS/LDS/SDS) converge to a bootstrap plus management servers. No more MongoDB death spirals.
AI-written summary · about
chapters (18)
- 0:00Introduction
- 2:56Service Mesh
- 4:11Envoy
- 7:14Lift
- 8:48Lift Architecture
- 12:33Dashboards
- 13:32Webscale
- 16:08Service Discovery
- 17:52Direct Connect
- 20:33Envoy for Developers
- 22:51Envoy Rollout
- 24:09Expectations
- 25:15Config Management
- 25:56Config Gen
- 27:05Hybrid System
- 28:14Universal Data Plane
- 29:41SDO Pilot
- 31:03Questions
related talks
32mHow Lyft Used Envoy to Rethink Microservice Development
30mFrom Four Wheels to Two
14mChanging Lanes with Lyft
33mFrom Four Wheels to Two
50mEvolution of a Microservice-Infrastructure
45mScaling Architecture at Lyft
49mBuilding and operating at scale with feature management
34mRunning Large-Scale Stateful Workloads On Kubernetes at Lyft