Why code your infrastructure?

This post appeared originally in our cloud microsite and has been moved here following the discontinuation of the blogs part of that site

One of the more popular buzz terms in infrastructure and cloud discussions these days is “Infrastructure as code”. But what is that exactly? How can infrastructure - previously supposed to consist of cabling, metal chassises and computer hardware - suddenly be lines of code? This article will assume that you are new to this field and will try to explain it from that point of view.

What it is

Very simply put, it is writing configuration files for how your infrastructure should look, and has been referred to as the Swiss army knife for both developers and systems administrators.

Wikipedia tells us that it “is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.The IT infrastructure managed by this comprises both physical equipment such as bare-metal servers as well as virtual machines and associated configuration resources.”

Although Infrastructure as Code (IaC) may be used to provision your data center, it is the advent of cloud computing that has really brought forth its value. Cloud computing, Infrastructure-as-a-Service (IaaS) and DevOps are all dependent on IaC, DevOps specifically because of the need for agile work processes and automated workflows.

So Infrastructure as code is just code.

Benefits

There has to be some, right?

• Speed and simplicity. IaC lets you spin up an entire infrastructure of virtual servers, launch pre-configured databases, network infrastructure, load balancers, storage and whatever else it consists of, simply by running a script.
• Configuration Consistency. Even with good documentations and standards, there will always be the chance of some deviation just from how that person executing the task chooses to do it. With IaC, the risk of this is severely reduced.
• Minimization of risk. IaC not only automates the process, it also serves as a documentation of sorts - a description of how to create infrastructure. This will make the anxiety of that one engineer that knows everything quitting fade away to nothing. IaC - done correctly - is like a blueprint of your datacenter
• Cost savings. Spend less time doing manual and repeating work and more on tasks that creates value for your company. IaC can also help you spin down again environments when they are no longer in use, saving money that way.

How to do it

There are a lot of tools available, both paid and free, open source and closed. Some may only be used with a specific provider, and some are provider-agnostic. We separate between configuration orchestration tools and configuration management tools.

Configuration orchestration tools are what you use to automate the deployment of servers and other infrastructure. 

Each of the three major public cloud providers each have their own tool, which can only be used there.  AWS has CloudFormation, Google Cloud has Google Cloud Deployment Manager, and Microsoft Azure has Azure Resource Manager. In addition there is Terraform from HashiCorp, which to some degree can be used on all the public cloud providers simultaneously and in addition integrate other third-party systems. The configuration languages used range from JSON and YAML to Python.

Configuration management tools are what you use for setting up and configuring systems, software and services on the before mentioned servers. There are a multitude of tools available for this, some of the most well-known are

• Chef - where you create recipes and cookbooks in Ruby
• Puppet - where you use Ruby to declare the state you want your systems to have and what they are supposed to do and Puppet will figure out how to get there (very simply put)
• Saltstack - also a declarative tool using Python * Some mentioned, a lot not mentioned, but not forgotten.

But it is - of course - not that clean and simple. There are some overlapping here between orchestration and management tools which you will find out once you start trying this out. Finding the tool(s) that best suit your needs is a major part of this undertaking.

(Some of the) Best Practices

• Codify everything. Every part of your infrastructure and system specifications that are put into code is a part where you have solid documentation and where you don’t have to put in manual work when having to recreate it
• Version Control. Source repository tools like Git, Mercurial, Subversion, CodeCommit or similar should/must be used. This way you can keep your sanity when trying to track changes, you can also do rollbacks easily and make collaboration work.
• Continuously test, integrate and deploy. IaC needs to be a part of your CI/CD plans, and is simultaneously a tool you can use to make your CI/CD work more smoothly.
• Make the infrastructure code modular. In the same way that “decouple” is a mantra when designing your virtual infrastructure, you should also apply it to infrastructure code. 
• Aim for cattle, not pets. While not practical in a household, it will make life so much easier when designing infrastructure. Any infrastructure resource is to be viewed as cattle that can easily be replaced as opposed to a pet that should be kept alive at all costs (and possibly for emotional reasons?)

Who does it and should you do it?

Everyone does it - at least they will tell you so. Remember the part about buzzword?

Should you do it? The answer is the same as to much of everything else in life - it depends. Chances are - if you are reading this, have understood most of it, and are starting to hum the IaC theme, you should. IaC will give you some, if not all of the benefits mentioned earlier both for large-scale deployments and for smaller more intimate server-environments for just the reasons listed earlier.

I was going to have a section at the end called “Why you shouldn’t do it”, but it didn’t seem to make much sense at this point.