I believe that Infrastructure-as-a-Code (also known as IaaC) becomes a central aspect of future infrastructure management. In this article I will outline some advantages and disadvantages of IaaC.
Advantages of IaaC
First, I believe that documentation which is asynchronous to the task itself tends to get outdated and ignored. If your job requires you to document a change in a wiki page (or similar to that), you might easily forget to track that change. This results in differences between effective and assumed implementation, which can result in service failures, security or compliance issues.
Second, I believe in automatization. Automating regular tasks makes executing them easier, safer and more resilient. Auomatization requires a structured definition of the required output, and by using IaaC the output is defined in some form of code. Automatization makes it easier to compare a desired state with an effective state, and usually computers tend to be more error-prone than humand.
And third, I believe in disaster recovery. A backup is useless, if one never tried to restore it. The same applies to infrastructure. Knowing that a brand-new and up-to-date infrastructure is just a click away, one can have a disaster recovery in place, at no additional cost.
But there are also some counterpoints to IaaC.
Disadvantages of IaaC
The first point is quite obvious: One size does not fit all. Having a heterogenous IT landscape, there might not be a tool available fitting all purposes and hardware sets one might have. Most IaaC toolsets tend to support „The Cloud“ only, so not having your application in the cloud might break the idea of using IaaC for everything.
Second, merging existing processes is not easy. Assuming you have all your applications already in the cloud, extracting the information from your provider and generating the sources required for IaaC is something almost all toolsets can do for you. What none of the toolsets can do is fitting easily into established processes and procedures. They not only might require some adjustment, they require it for sure. And having to automate a complex process is not going to be easy.
Providers
There are several providers and toolsets for IaaC. We at Global Elements believe in the strenghts of Terraform, one of the earliest providers of IaaC. With Terraform, you write code in a domain-specific language that is very close to JSON.
Like virtually all IaaC providers, Terraform uses something called „state“. The state describes the last applied version of the infrastructure definition. It is used to compare the latest applied state, the desired state and the effective state. This allows to make sure that manual changes are detected (and then overriden) by applying the desired state to the infrastructure. Using this process, manual changes are automatically overriden. This requires an engineer to always write changes to the Terraform definition.
Terraform has support for almost any of the well-known Cloud providers, including Amazon, Microsoft, Google, Cloudflare, DigitalOcean and quite more.
Summary
By using Infrastructre-as-a-Code, you receive a structured and automatically documented definition of your current infrastructure. You can detect (and override) manual changes by applying a desired state to the current state. By this process you will make sure, that everyone is forced to use the defined IaaC toolset. IaaC is nothing new, but it is still not yet widely adapted. There are some disadvantages when having hybrid infrastructure, but IaaC toolsets provide still more advantages.