Why do we love Infrastructure as Code (IaC)?

Infrastructure as code (IaC) is a declarative way of provisioning and managing infrastructure through code on cloud platforms. It is a method of deploying and managing resources on cloud platforms using a configuration file or template that is usually written in JSON or YAML format. In essence, it's a method of automating infrastructure deployments using code.

Why do you need it?

Without IaC for infrastructure deployments, these deployments are made through the cloud platform UI console. One must start by manually provisioning the infrastructure in the development phase. However, post-development, when it's time for production deployment, it becomes incredibly challenging to replicate all the steps undertaken during the development. Hence, achieving perfect deployments on the first attempt, in this case, becomes extremely rare unless it’s a minor one.

To address this challenge, one must document all specifications and steps before going to production and follow those steps for the production deployment.

This is where the problem lies. The entire deployment process through the console, therefore, requires heavy human interaction making the workflow prone to human errors. This ultimately leads to unintended infrastructure deployment and makes the process extremely time-consuming and cumbersome.

Therefore, to avoid these possible errors, automation is necessary for the deployment pipeline, which is what IaC does. With IaC, the user just needs to provide the configuration to the IaC tool, and the tool will handle the provisioning and managing of the infrastructure. The same configuration file can be used to create a replica of infrastructure in a different environment by providing a few dynamic parameters. This also helps increase productivity as the user is only writing the configuration files, and much of the heavy work of deployment and management is automated via tools.

Types of IAC

There are two ways to implement IaC:

• Declarative: In the declarative approach, the developer needs to define the desired state of resources, and IaC tool will create/update the resources. Many IaC tool like AWS Cloud-formation and terraform use a declarative approach. Scaling up/down or configuring resources is easy in a declarative approach, as the developer just needs to define the desired state. The process of achieving it is handled by the IaC tool.

• Imperative: In the imperative approach, the developer needs to define specific commands in the required order to achieve the desired state. Similarly, for scaling up/down, the developer needs to write commands to achieve it.

In the imperative approach, if the developer runs the same script repeatedly, it will try to make duplicate resources, while that’s not the case with the declarative approach no matter how many times the developer runs it.

How do we use it?

At Blue Sky Analytics, we prefer to automate our tasks as it helps minimize human intervention and ensures increased productivity. Once set up, although all these automated flows require little human interaction, they do require a monitoring system. IaC takes this automation one step ahead by automating provisioning and managing resources. All our resources are created through IaC, even our IAM user accounts and associated policies.

In AWS, we use Cloudformation (CFN) for IaC. Everything is done by the automated flow, from pulling codes from GitHub to deploying to AWS. All of our AWS infrastructure is built through IaC. In fact, our pipelines are templated with IaC & thereby, as it improves, updating the pipelines becomes very convenient.

“I have written so many cloudformation templates that I feel more comfortable writing CFN templates for resources than creating them through a console.”

Before making changes, AWS CFN creates a changeset that basically tells what changes our CFN template will make to our infrastructure. This provides more confidence before deployment to ensure correct resources are created/updated.

Not just CFN, but other tools like terraform that we use for our external resources also provide output difference before deployment. To showcase the output difference, the IaC tool compares your new template/configuration file to a previously deployed template/configuration file.

However, you can not expect your deployment to go error-free all the time; there can be cases when you end up providing the wrong values in the resource configuration or when resources with the same ID already exist. AWS CFN handles these cases pretty well. CFN will first try to make changes, and if an error occurs, it will revert all the applied changes to bring your infrastructure back to a stable state and log the error for you. The cloudformation console is also great for monitoring your deployed stacks through IaC.

Why do we love it?

• Faster Deployment: Everything goes into a configuration file, and all resources are created/updated by just deploying the IaC template, making CI/CD fast.

• Reduce errors: Given that IaC automates resource provisioning and managing, it’s less prone to human errors.

• Easy deployments of multiple environments: Usually, IaC tools provide a method to pass dynamic parameters to a template. Hence the same template can be used to create resources in various environments. For example, you want a more powerful machine in production than staging. You can easily configure these using dynamic parameters.

• Easy to debug: IaC configuration files/templates are versioned so it's easy to go back to a stable state if the new one is faulty or trace back and plot the version and change that caused the bug

• Consistency: IaC is idempotent in nature, so the same configuration file will always create the same resources. This helps in having a replica of the production infrastructure to test the applications. With the help of parameters, you also get the flexibility to deploy as many variations as required.

• Easy to scale: As in the declarative approach, we just need to define the desired state of the resource. This makes scaling up and down as easy as increasing or decreasing a number.

• Low cost: Due to being automated IaC can help in cutting human costs.

• Decentralized Access Control: The manager can assign a task to someone in the team and get it done without exposing the Access Control. Any developer can thus write an IaC template and which then be deployed.

• Closer integration of application & infrastructure code: The application developers build a good understanding of the infrastructure that the application with run-on and interact with, instead of outsourcing it to a separate DevOps person who is not involved in application logic.

Cons (What more do we wish to have!)

• No single IaC tool works everywhere: There is no particular IaC tool that works everywhere. While sometimes you will have to use cloudformation, other times terraform or, in some cases, a combination of ansible and terraform might do the trick.

• Monitoring challenges: Depending upon the tool you are using, monitoring can be challenging sometimes.

• Timeout bugs: Very rarely, you can get a bug where the deployment goes wrong and the stack is stuck. In that case, one needs to wait for the default CFN timeout before further deployments can be made

End note

Hopefully, you found the above breakdown of IaC interesting and learned something from it. Or maybe, you might have a thing or two to teach us, in which case feel free to reach out. Learning is a never-ending process, so stay tuned to our blogs as we have various other tools in our garage.

Additionally, if this is something that excites you and you would like to work with people trying to tackle the impossible problem of climate change, we are looking for DevOps Engineer, Full Stack Developer, and Frontend Developer.