The Deployment Elephant
Tim O’Reilly covers much of what’s been crossing my mind recently in Operations: The New Secret Sauce. The really successful people are those who (like Google) have solved, and are continuing to solve the really hard problem of deployment. There is a huge gulf between programmers and sysadmins that needs to be crossed so you can get software that works really well. It’s all very well writing code that works “great on my PC”, but when you have to stick it on a Unix server blows up (reminds me of the “Best Viewed On My Monitor” graphics that festooned the web a few years back). We can and must do better.
Part of the problem is that nobody is seriously talking about deployment. During our company’s recent move towards Java, I’ve found it seriously hard to work out what best practises are and have already gone through several painful experiences working things out. Yes, this is part of the normal learning curve. But it would have been really, really nice to look them up in a “Deployment Patterns” book.
Update: on a tangentially related note, Steve Loughran notes:
There is a very simple test to see if the deployment process is working. If you have to go into the air-conditioned server room on a weekend or on your vacation, deployment is broken. If you are scared of the mobile phone ringing, because it may be the operations team, deployment is broken. If you are a week away from going live and you haven’t started bringing up the server, then the process is broken, you just don’t know it yet