The author makes some amazing points that I'm surprised intelligent people are missing.
Let me give an example. We are currently migrating from storing blobs of data in Voldemort (a key/value store) to storing them in S3. They should have never been in there in the first place but whatever. We're going to do it with "zero" migration time. In fact we're already doing it.
- Set up a job that copies existing data in Voldemort to S3.
- Deploy a minor release of our code that multiplexes the current writes to both Voldemort and S3.
- Continue migrating existing data
- When existing data is finished migrating, deploy a new release that forces all traffic to S3 instead of Voldemort.
People need to learn to do things like dark launching and feature flags. Dark launching let's you exercise new code paths with no impact to the user. Feature flags give you the ability to enable to features to some or all of your users. Feature flags are awesome ways to A/B test as well.
People need to stop doing stupid shit like redefining what some property means mid-release and instead define NEW properties and deprecate old ones in subsequent releases.
Same goes for schema changes. If some part of your code base cannot tolerate an additional column that it doesn't need, that's a bug.
You can also adopt some configuration management that allows you to provision duplicates of the components you're deploying so you can swap back and forth between them in the case where you might have a breaking release. That's what we do and it's one of the upsides of using EC2.
All of this requires discipline and dedication but the benefit is so worth it. You have to stay on top of dependencies. You can't let bitrot take hold by going 4 major revisions without upgrading some package. We did and it bit us in the ass.
This is why we adopted the swinging strategy of duplicating our entire stack (takes about 30 minutes depending on Amazon allocation latency) on major upgrades.