by Andy Patrizio

What is ‘infrastructure as code’ and why should you embrace it?

Dec 22, 2015
Data CenterVirtualization

Sometimes referred to as programmable infrastructure, IAC is a good way to safely embrace IT automation and get your ‘shadow IT’ under control, too.

One of the major trends in IT over the past few years has been increased automation and a concurrent decrease in the need for human or manual intervention. Virtualization has made it possible to spin up a virtual server space for developers to do their work in isolation of the production systems, and hypervisors like VMware and Hyper-V make it possible to get one running in under 20 minutes. 

Of course, provisioning a virtual workspace isn’t always so simple. The process may be a lot longer, or the people who have clearance to do it may not be available. A developer may request a virtual environment to do development work and then spend two weeks waiting for the VM. This is where Infrastructure as Code (IAC) comes in. 

IAC is a type of IT infrastructure provisioning process where systems are automatically built, managed and provisioned through code, rather than less flexible scripting or a manual process. That’s why IAC is sometimes referred to as programmable infrastructure. It makes the process faster and eliminates human error, once you get your code solid. 

“Infrastructure as code is an approach to managing IT infrastructure for the age of cloud, microservices and continuous delivery, says Kief Morris, head of continuous delivery for ThoughtWorks Europe. “The basic idea is that you treat your IT infrastructure as software. This helps you to make changes to it rapidly and easily, at the same time safely and reliably.” 

By using code to automate the process of setting up and configuring a virtual machine or container, you have a fast and repeatable method for replicating the process. So if you build a virtual environment for the development of application, once you are ready to deploy you can repeat the process of creating that VM simply by running the same code. 

IAC isn’t all that different from scripting in terms of automating an IT process. The problem with scripts is that they are typically used to automate static steps and don’t have flexibility for complex actions. IAC gives you the versatility of code in a script-like environment. IAC dictates what kind of infrastructure is produced. So instead of manually configuring a server farm, IAC code does it for you. 

[Related slideshow: Top cloud Infrastructure-as-a-Service vendors] 

At the same time, the code also becomes your documentation, says Chris Riley, a co-founder and DevOps analyst with, which bills itself as a tech evangelism service for developers. “It is a process change around change control and documentation infrastructure. So anyone can reference a script and know what the configuration is for server type or node type,” he says. 

The ingredients of infrastructure as code 

The first thing to remember is that IAC is not a product, it’s a methodology. It’s a process to an end, which is the rapid deployment of a virtual environment. 

To properly embrace IAC, you need three things: agile development processes, a DevOps environment and the tools to write the code. DevOps and agile go together as it is, as both are about speeding up development and empowering the coders to get their job done faster. 

Agile is necessary because IAC is all about speed. “One of the big things is your development team will move fast. They are embracing new approaches to software development using agile. Actually, their sprints are much faster, so waterfall concepts are going out the window,” Riley says. 

“Agile is about embracing change, treating it as an expected thing, and even a positive, as opposed to old-school, viewing change as a problem,” says Morris. “If you use automation tools but still manage your infrastructure with the Iron Age approaches to change management, you’re losing the benefit. IAC is more reliable, particularly if you use Agile engineering practices like test driven development, continuous integration and continuous delivery.” 

After that, you need the language of choice, and for most, it is either Chef or Puppet. Both languages are made for this technology; Chef is designed for fast collaboration in a DevOps environment and Puppet is for automating the process of building an infrastructure. 

“I think you can look to Chef and Puppet as examples of best practices that are pretty mature,” says Morris. “As in, the way they are designed to manage infrastructure.” 

“Chef or Puppet have frameworks that make the job easier. It all depends on how customized your stuff is and how you want it to be reusable by other people. Chef or Puppet let you make reusable objects,” says Sean Kenefick, research director for application platform strategies at Gartner. 

IAC is platform-agnostic. Puppet and Chef are both available on Windows and Linux, and Kenefick says he has as many clients running Windows environments asking about IAC as he does clients running Linux. 

The one thing that you might find lacking is good documentation and studies. IAC is still a new concept, and there isn’t a whole lot for an interested party to study unlike, say, enterprise Java development. There are countless books on the subject and an endless number of Websites on Java coding. That’s because Java is 20 years old. IAC isn’t even two years old. 

[Related: How to tackle change management in an era of automation] 

“The concept and many of the tools are pretty mature, but organizations are still figuring out how to implement it and how to adapt their processes, structures, and so on,” says Morris, who is writing a book on IAC because he felt there was too little good documentation. For now, he says if one wants to learn best practices for IAC, they need to read blog posts, articles, and attend DevOps conference talks. 

The benefits of infrastructure as code 

Embracing IAC is primarily going to keep your developers happy. That means two indirect benefits: a reduction in the notorious “shadow IT,” and reducing expenses from man hours. 

“From a monetary perspective, you are looking at a way to run things much more quickly and less error prone, there is much less risk. If you can reduce how long it takes to do something from four days of man hours to 15 minutes of man hours, then that person is able to do other things. So from a time management perspective that’s helpful,” says Kenefick. 

The other benefit is that shadow IT is reduced because many developers don’t want to wait for however long the IT department needs to provision a new VM for them to do work. 

“The nature of some developers is they will do their own thing no matter what,” says Riley. “The biggest complaint a developer has is they want a VM right now, they don’t want to wait. If they don’t have that ability they will turn to doing it themselves, like VirtualBox, or they will go to Docker, both of which pose risks.” 

Docker has a public hub of dock images to help people jump start their work. The problem is you have no idea where the image came from or what code is on there. It might have unwanted apps, spyware, malware, Heartbleed, anything. And without an audit trail, there’s no way to trace the problem back beyond the image you used. 

There is work being done to address this, by Docker and others, such as DCHQ and, both of which are helping build audit trails and provisioning around Docker containers. 

Going forward, Kenefick says the ability to manage resources in cloud environments are next, although he adds we’re already somewhat there because Amazon provides tools to develop IAC in the cloud. The trick is they are not always easy to use,” he added. 

He also says the skillset of developers will be indicative of how well you embrace this as a practice. “The tools make it easier to do what we should have been doing for years. It became a DevOps practice more for speed,” he says.