Scaling Chef Emotionally
summary
Slack runs Chef on a single stateful backend then migrates to AWS managed services (Aurora, managed Elasticsearch, NLB) and stateless EC2 frontends to stop outages; automated testing lands via Test Kitchen plus serverspec and a CI workflow that uses a custom gchen wrapper to run convergence and new-host tests pre-merge; release controls include feature flags and zonal rollouts, a CAB then a delegated deputy model, and an 84,000 cookbook versions incident that forces cleanup and drives a plan to shard Chef servers for scale.
AI-written summary · about
chapters (12)
- 0:00Scaling Chef at Slack
- 2:31Manual scaling challenges
- 6:34Re-architecting Chef backend
- 9:42Developer workflow limits
- 13:13Breaking point and freeze
- 15:42Safety processes
- 18:31Automated testing with gchen
- 23:29Measuring infra safety
- 26:14Upgrading Chef versions
- 29:04Future sharding plans
- 31:12Big events in scaling
- 32:56Q&A
related talks
18mChef On The Train
34m"Acing" Infrastructure Testing with Chef
42mCaptial One's Newly Designed Fully Automated, Scalable, and...
33mDeveloping for Multi-Component Environments While Keeping Your Sanity
38mAn Approach to Air-Gapped Deployment
25mCooking with Chef - Your servers will thank you
40mJenkins and Chef: Infrastructure CI and Application Deployment
38mChef for OpenStack Overview
