Saturday, January 23, 2010

Microsoft does not want your money!

This just in... Microsoft does not want your money! At least for up to 24 Hours beginning 10pm PT Monday, January 25th.
As part of our continued efforts to improve the Zune Marketplace service onXbox LIVE, Zune Marketplace will be undergoing scheduled maintenance for up to 24 hours, starting 10:00 P.M. (PT) on January 25, 2010. During that time, you will be unable to rent or purchase video content.
How is it o.k. for any major web business to go offline for up to 24 hours? How many people would have started using the Zune Marketplace on January 25th that never will now? I know, you're thinking nobody - except maybe this guy:

All joking aside, designing solutions to required downtime is not hard to do. I'm responsible for an online education site that can't have that many more users than the Zune. Yet, my team (which I'm sure is significantly smaller, but better looking than the team working on the Zune Marketplace) managed to release many times per week with only :30 mins of scheduled downtime for the entire year (the :30 mins was avoidable, but would've required ~3 days of work).

Typically, all you need to do is decouple client releases from application server releases from database releases. Then release in reverse order... required db changes go before application server releases go before client releases.

Now, we're starting work on a continuous deployment system so that all deployments happen on check-in. (Don't worry, there will be automated tests.) If you're a Microsoft engineer, read more at: Read Eric Ries's post on Continuous Deployment in 5 Easy Steps.


  1. Did you notice that this article was written two days before April Fools Day? ;-)

  2. Ha! Good point, he's had multiple other posts on continuous deployment... like this one:

    However, this may just be an elaborate April Fool's hoax :)

    I'm not sure if you can get there with the stuff you're working on, but I know for most coders minimum friction between code and release maximizes the sense of accomplishment. Also, if you're using standard practices for branching, QA and Deployment, I think you just need to ask yourself how much risk it reduces vs. how much your investing in it.

    I'll keep you posted with how our experiment goes!