Automating the component maintenance - Fleet management at Spotify
summary
Spotify builds a fleet management system that targets ~40,000 components (about 3.5–4k backend services), authors changes with Docker-based code mods, orchestrates them with Fleet Shift, and creates over 500k PRs so far. More than 130 fleetwide changes run daily, ~75% of PRs auto-merge under rules, Log4j fixes reach 80% managed services in under six hours, and framework rollouts drop from ~200 days to a few days. Tooling includes Backstage, BigQuery, rewrite, and a Firewatch monitor for pausing rollouts.
AI-written summary · about
chapters (29)
- 0:00Introduction
- 0:54Microservice architecture
- 2:24Dependencies
- 4:39Growth over time
- 6:19Maintenance and migrations
- 7:48Fleet first mindset
- 8:42Monor vs poly repos
- 11:25The problem
- 15:18Code mode
- 17:39Frameworks
- 18:22Cloud resources
- 19:53Fleet shift
- 22:41Autom merging
- 24:39Culture
- 28:39Where we are
- 31:04Log for J vulnerability
- 32:37Time to roll out changes
- 35:00Repaving
- 36:23Whats next
- 37:34Release externally
- 38:20More depth
- 39:30QA
- 41:44Integration testing
- 46:57Firewatch
- 48:22Push backs
- 51:47Dependency graph
- 54:57Technical maturity
- 56:57Breaking changes
- 59:27How to find dead branches
related talks
09mSelf-Service Infrastructure
34mThe Spotify Story: Moving from NIH to an Active CNCF Community Member
20mSpotify's Growth Exposed the Abstraction Paradox
12mEngineering Productivity, Infrastructure
35mTaming a beast
57mA continuous fairytale
33mEvolving a Continuous Delivery Workflow
45mNetflix’s Secret to Safe Automation at Scale