The Biggest Challenge for Infrastructure as Code

What do you do when you come across a piece of open source software that you’d like to try? You could download its source code tarball, extract the files, build and install it following the rules and conventions for a given programming language (./configure && make && make install, ruby setup.rb build, python install, perl Makefile.PL) - and you end up with a usable product. This simple fact is at the very core of entire open source ecosystem - without an easy and reliable way to transform source code into runnable software, open source potentially would not even exist.

I think that the biggest challenge for Infrastructure as Code today is its current lack of anything resembling a Makefile - a relatively simple description of how input could be transformed into output ready for use end to end, given a set of basic tools or a preset build environment (for example, for a project written in C it would be apt-get install build-essential on Debian and its derivatives). If you want an example, please take a look at deployment instructions for openstack/nova ("on the cloud controller, do this... on volume node, do that..."). While it is indeed infrastructure code, its end-to-end build and deployment instructions are provided in textual form, not as code.

Why is it a problem you may ask. First and foremost, build/deploy instructions provided in textual form can’t be easily consumed by a machine - it feels like we are back in the dark ages, without APIs where all work must be performed manually.

Secondly, because they are not fully formalized, they can’t be as easily shared - there could be many uncaptured context requirements that could lead to different people transforming identical inputs to outputs that would not function identically. And if they are not shared, same functionality is being worked on by many separate teams at the same time, which leads to incompatible, sometimes competing implementations and creates wasted effort by not allowing code reuse.

Thirdly, since they are not code, they are not as easy to test and verify test coverage for, or to fork and merge, or to port to other platforms.

My point is that while individual parts or steps of an infrastructure deployment could be automated, a whole thing rarely is, especially when a system is to be deployed to multiple hosts connected over the network. This would be similar to a software project with various directories, each with its own Makefile but without a top-level Makefile - such that you’d have to follow a HOWTO telling you which arguments to pass to make in each directory and in which order to run the commands.

What to do? I call on all infrastructure projects to make every attempt to ship deployment instructions not as textual step-by-step howto documents, but as code - be it Chef cookbooks, Puppet recipes, shell scripts, Fabric/Capistrano scripts and so on, or a combination of any of the above. Please consider providing cloud images (in at least one region of at least one public cloud) with your canonical build environment (your equivalent of build-essential). Please consider including canonical network topologies for your deployment - since you can't predict IP addresses each user is going to allocate, all configuration files will need to be autogenerated or built from templates.

I am well aware it’s easier said than done, but if we do this, I hope a tentative consensus on best practices for infrastructure as code deployments could emerge over time which could then facilitate creation of a common “infrastructure make” tool.

Categories: devops | infrastructure-development |

Comments (6)

jameswhite // 18 Aug 2010

IsConf is configuration management using makefiles.

Good idea at first, falls apart in practice.

azizshamim // 18 Aug 2010

Looks like the argument is essentially that it can't be turtles all the way down, i.e. at some point there has to be human intervention. I think the point of devops is to move human intervention to a point where work substitution by a computer cannot be done, or having it done is a lower return on investment. i.e. what version of code should I run, not "./configure && make && make install"

Dmitriy // 18 Aug 2010


Why does it have to be human intervention at some point? Why can't it be automated all the way?

I am not saying it's easy but it should be the goal imho.

Without this, it looks to me like it's going to remain "infrastructure as pseudo-code" and not "infrastructure as code."

jtimberman // 18 Aug 2010


Opscode makes Amazon EC2 AMIs available for 32 bit and 64 bit instance types in the us-east-1 region, and provides instructions for users to create their own on the Chef wiki.

We're testing new AMIs for 0.9.8 (current release).

Chef has integration with a variety of cloud computing providers, too. Users can use the Knife command-line tool to launch instances in EC2, Rackspace and Terremark that are automatically configured to be Chef clients based on the local user's Chef environment.

Stop by our IRC channel or mailing list if you have any questions!


Adam Jacob // 18 Aug 2010

Also, we have openstack cookbooks that translate those instructions into chef available to developers at:

They work for deploying swift as an all-in-one, and nova for development.

Dmitriy // 18 Aug 2010


Thanks for the pointer!

This is exactly (or almost exactly - will have to try it out) what I want every infra as code project to ship.

I used nova just as an example, though - nothing against openstack project :)