How Spotify Migrated Ingress HTTP Systems to Envoy
summary
Spotify migrates its HTTP ingress from an Nginx/HAProxy/Puppet mess to an Envoy + custom control plane exposed via Google L7 load balancer, running ~100 eight‑core proxy instances. Migration moves ~150 web services (75% migrated with scripts, 25% manually), starts with the Web Player, and achieves GA before hack week while cutting infrastructure cost. Team hits issues: Envoy CPU limits (600 QPS saturates a 8‑core VM), SLO loss (used error budget) and socket/feature gotchas.
AI-written summary · about
chapters (20)
- 0:00Intro
- 0:29Agenda
- 0:59About Spotify
- 2:11Really old spotify perimeter
- 3:50Old perimeter - HTTP upstreams
- 5:14Why migrate?
- 6:18A unified perimeter
- 7:34Why Envoy
- 8:44New Edge overview
- 10:37New Edge risks
- 11:22Migration - Goals
- 12:51Migration - First step
- 13:50Migration - More traffic
- 15:28Migration - What was left?
- 16:25Migration - What we did
- 17:57Migration - How it went
- 19:32Learnings and Failures
- 21:20Some Envoy improvements
- 22:04Future plans
- 23:16Thank you!
related talks
36mHow Spotify Migrated Ingress HTTP Systems to Envoy
31mHow We Moved Spotify To a Proxyless gRPC Service Mesh
27mAdventures in Rate Limiting: Spotify’s Journey Writing a Scalable Envo...
23mBridging the gap between on-prem and cloud: a story about...
33mGet to know Envoy - the modern proxy for cloud-native infrastructure - Baptiste Collard
33mRunning Envoy as an Edge Proxy
28mEnvoy Project Intro
31mEnvoy Project Intro – Matt Klein & Jose Nino, Lyft