Spinnaker at Scale for Snap's Multi Cloud Service Mesh
summary
Snap migrates a single‑region App Engine monolith to a multi‑cloud service mesh using Envoy sidecars, a custom in‑house control plane, and a Switchboard UI; Spinnaker deploys to ~30 Kubernetes clusters and new clusters appear in about 8 minutes. Static credentials disappear via a rotating sidecar that injects ephemeral AWS keys, and Redis caching is offloaded into MySQL while splitting cloud driver workloads and node pools. The system runs in production but required fixes for Redis/cloud‑driver scalability and added auth proxies and network policies for safety.
AI-written summary · about
chapters (14)
- 0:00Introduction and team overview
- 1:24Service mesh problem and goals
- 3:56Snap service mesh architecture
- 6:00Spinnaker's role in standardization
- 7:48Initial challenges and workarounds
- 10:14Scaling Redis and cloud driver
- 13:05Static credentials elimination
- 16:10Security hardening and access control
- 20:29Current production setup
- 26:50Integrating Spinnaker with service mesh
- 30:04Kubernetes cluster provisioning
- 33:31Service deployment workflow
- 37:42Future improvements and challenges
- 42:19Q&A session
related talks
19mSpinnaker @ Upside: Getting Started, Establishing Culture & Deploying Microservices with Confidence
18mOvercoming the challenges of using Spinnaker as a multi-tenant CD service
33mPanel Discussion: Spinnaker Success - CD as a Service using Spinnaker
30mSpinception: Deploying Spinnaker with Spinnaker
36mSpinnaker - Land of a 1000 Builds
28mCisco Success Story: Enabling Diverse Application Use Cases using Spinnaker
52mContinuous Deployment to the Cloud using Spinnaker
25mEnabling Diverse Application Use Cases using Spinnaker