Infrastructure as Code, also known as IAC, is exactly what it sounds like. Infrastructure written as code. We can use IAC to provision and manage our infrastructure both in the cloud and for on-premise systems. There are considered to be two types of approaches to writing IAC, declarative and imperative. Declarative IAC, is telling the system what we want our system to look like. Imperative is when we define logic in order to tell our system how to behave. One of these aren't necessarily better than the other, they're just different. Declarative IAC, stores a state of what of our system looks like. This means it is idempotent when building and destroying infrastructure. Because it always knows what our system looks like, it can detect changes that might result in duplicates, before they are made. This is not the case of imperative IAC. Imperative IAC has no sense of what has our system looks like. It only executes the commands given. Let's look at an example. 

We want to create an S3 bucket in AWS using both an imperative and declarative approach.

One imperative approach to this is using AWS CLI.

$ aws s3api create-bucket --bucket "my-bucket"

Now, let's look at how we would do the same operation with a declarative approach using Terraform.

resource "aws_s3_bucket" "my_s3_bucket" {
    bucket = "my-bucket" 
}

Both these approaches achieve the same thing, just in different ways. One thing to mention here, is that the imperative approach is not idempotent. If we run this command twice, we'll get an error message telling us that bucket already exists. In the declarative approach, Terraform already knows that the bucket my-bucket exists, and therefore does not try to create a new bucket.

Why IAC?

Provisioning infrastructure in the cloud manually, can be a bad idea. It's easy to lose track of what has been deployed and unexpected costs might occur from hanging resource you forgot about. This is especially true when building large infrastructures. To solve this, we write our infrastructure as code. This makes it easy to managed and configure the provisioned infrastructure. IAC also makes distributing our resource configurations between teams, workspaces and developers easy. IAC will allow us to version control our configuration files and go back in time to review who and what changes was made previously to our infrastructure. The three main benefits of IAC are,

• More effective provisioning and maintenance of infrastructure.

• Higher reliability, less human-made errors.

• Much more cost effective.

One of many benefits of cloud infrastructure is dynamic environments. The ability to dynamically scale your environments to save costs is one of the main perks of cloud environments. IAC makes this process tremendously less difficult. Thanks to CI/CD pipelines and automation scripts, we can build and destroy infrastructure at the click of a single button. A common scenario for this would be down scaling your development environment after working hours. We've recently had a client that had their development environment up and running 24/7. Considering that the client only used the development environment 8 hours a day, Monday to Friday, they of course wasted a ton of money leaving the environment up all day. After configuring some relatively simple CI/CD pipelines and automation scripts, we manage to reduce the clients development infrastructure costs by almost 50%. This of course would be impossible to do without the power of IAC.

Difficulties with IAC

IAC tools and technologies are evolving at at very high pace. In my opinion, one of the more difficult aspects of developing IAC, is keeping up with the latest updates and technologies. This is especially true when integrating multiple service together when developing infrastructure. Here's an example. 

Let's say your development team is writing IAC from their computers using Terraform. They all push their code to e.g Gitlab. In Gitlab, there is a CD/CD pipeline running automation scripts and provisioning the IAC to the cloud. Within all these steps, there are points of failure. Terraform might introduce new features and remove old ones. This can make some of the resources used in the code, not function like they used to do. Another point of failure might be within the Gitlab CI/CD pipeline. The docker image used to build these Pipeline jobs, might also introduce new feature and remove old ones, making parts of the pipeline broken. Perhaps you run some automation scripts that requires a 3rd party application to work. This 3rd party application might also be subject to change. I'm not saying using this type of integration is a bad thing. Only that it requires continual maintenance to make sure the whole process runs seamlessly.  

Another example of difficulties with IAC is mixing in manual changes. Making changes to resource that are provisioned with IAC, manually, is generally a bad idea. Most IAC tools works by using a state. The state is information about the real world applications deployed to your cloud environment. When deploying IAC to the cloud, your IAC tool, e.g Terraform, updates its state file to match the newly created resource and/or changes made to existing resources. If you were to manually update your cloud environment, the IAC tool might fail when provisioning IAC to the cloud because its state does not match the real-world environment. 

Summary

Writing IAC, instead of manually changing your environment, is a much faster, safer and less costly affair. IAC makes provisioning infrastructure through CI/CD pipelines and automation scripts possible. We usually divide IAC into two approaches, imperative and declarative. Imperative is defining how we want to achieve a change in our infrastructure, while declarative defines what we want our infrastructure to look like. The later approach usually uses a state to "know" what our system looks like, and uses this when updating our infrastructure.