One show-stopping problem with automation is that the more dynamic the recipe is for the automation, the slower it ends up running in the operational environment. I ran into a discussion of this problem yet again in a presentation on the Chef Web site.
Chef, of course, is one of a new crop of vendors hawking automation tools for the Cloud. Instead of manually configuring your Cloud environment, the argument goes, use Chef (or Puppet, or one of several other similar tools) to write a recipe, or script, or template for that configuration, so that you can create as diverse and dynamic a configuration as your heart desires.
As the presentation laments, however, configuring, say, an Amazon EC2 instance using a recipe can lead to painfully slow boot times. But have no fear, Amazon has the answer: Amazon Machine Images (AMIs), which are preconfigured in a plethora of different ways to meet a wide range of possible needs. Simply pick the one you want, install it, and you?re off and running.
There are two main problems with the AMI approach, however. First, you need a boatload of AMIs ? and the list of available ones keeps increasing. Second, there?s always the chance that no AMI will quite fit your requirement. Then you?re back to hacking individual VMs, which everybody wants to avoid.
The current solution to this conundrum is to mix and match ? prebake certain things, but put recipes in your cookbook for others. Then the challenge becomes engineering your cookbook: handling lifecycle-centric issues like QA and versioning for the cookbook itself.
True, performing such engineering is DevOps at its finest, with ops folks looking to dev folks for engineering pointers they can apply to the automation of the ops environment. But if this entire picture of engineered cookbooks with a mix of pre-baked and customized recipes strikes you as inefficient, you?re not alone. Have we really done everything we could to leverage Cloud Computing and DevOps to squeeze inefficiencies out of our approach, or have we simply moved those inefficiencies around a bit?
True, the Cloud-savvy success stories today have navigated these waters and figured out how to make such cookbooks work for them. But this entire approach still smacks of the horseless carriage: taking a new paradigm and bringing old procedures and approaches to it because that?s how you?ve always done things. Any developer who has made the decision whether to use a prebuilt code module or build one themselves has worked through the same tradeoff. So what else is new?
What we need is a new paradigm for automating interactions that rises to the level of expectations that the Cloud sets for us. We need better than pre-written scripts mixed together with pre-baked machine images. The Cloud demands the ability to build fully dynamic, customizable configurations of anything without sacrificing performance. Anything less and you might as well be saddling up for a ride.
