What is IAC?

Infrastructure as Code (IAC) is using a programming approach to replace the traditional manual provisioning of infrastructure through admin consoles/GUI. Instead of navigating through various screens to deploy/enable infrastructure and manually configuring them, we achieve those same tasks through the usage of code approach.

IAC is used extensively in dynamic infrastructure environments such as public or private cloud platforms because of its ability to provision and/or deprovision a large number of resources quickly. IAC allows us to scale our infrastructure in a short amount of time.

Infrastructure As Code is writing and executing code in a way to define, deploy, and update a given infrastructure. This includes networks, routes, load balancer, compute instances, storage buckets, etc.

Terraform is one of the many IAC tools (Its Code, but we still call it a tool)

Pros of using IaC

A few advantages of using IAC approach are:

• Elimination of manual tasks – A management tool does the provision and configuration of servers and other infrastructure elements on demand.
• Removal of dependency on other entities – Once you write the code for any component and define all the dependencies, you eliminate the need to involve other teams as it is already vetted and ready to go. So, the setup is one-time effort.
• Automation – Infrastructure elements are built, managed, and provisioned automatically through the Code. Updates are installed via the Code.
• IAC approach makes infrastructure consistent, testable, maintainable, reusable and extensible
• Elimination of manual errors once you have a fully functional and thoroughly tested code.
• The Code also acts as documentation.
• We can implement source control on the Code for infrastructure and keep them in a repo making it easily accessible to the entire firm as a library.
• The reusability and flexibility of IAC enable faster delivery of any new infrastructure.

Popular IaC tools

The most popular IAC tools are:

• Terraform – creates execution plans outlining what will happen when the code will be run, uses own domain-specific language Hashicorp Configuration Language that is JSON-compatible
• Pulumi – helps to define cloud apps and infrastructure in any language and deploy to any cloud
• Ansible – describes how the system and the components relate to each other instead of managing systems independently
• Chef – uses Ruby-based DSL, follows a procedural approach to configuration management where it is necessary to describe the procedures that will result in getting to the desired state.
• Puppet – enforces the desired state automatically and fixes incorrect changes, the state of the infrastructure, and what is expected of it to have to be defined.
• Docker – helps to create containers that pack the dependencies and the code together, therefore allowing the application to run in any environment.
• Saltstack – takes an ‘infrastructure as data’ approach, its declarative configuration patterns are written in Python and are language-agnostic
• AWS CloudFormation – allows coding the infrastructure to automate the deployments, usage limited to AWS

What is Terraform?

The four general categories of IAC scripts are:

1. Ad hoc scripts
2. Configuration management tools
3. Server templating tools
4. Server provisioning tools

The focus of this essay, Terraform, is one of the server provisioning tools, which means it is responsible for server creation.

Terraform is an open-source tool by HashiCorp, written in the Go language, compiled into a single binary; An infrastructure is deployed, or a server is built using a shell from this binary.

The terraform binary can make API calls to Google Cloud, AWS, OpenStack, etc., with the help of Terraform providers maintained by the community.

Link to Terraform Docs in Hashicorp

Terraform vs. A Few Other Tools

Terraform vs. Chef

The chef is a configuration management tool, where Terraform is a provisioning tool. The chef is concerned with the installation and management of software on existing servers. In contrast, Terraform provisions the servers themselves and can be used to install the desired software and configure it. Chef defaults to a changeable infrastructure standard, making it hard to diagnose configuration bugs. In Terraform, every change is the deployment of a new service configuration. Chef represents a procedural style to code writing and needs a master server for state storing and agent software on each server it is supporting.

Terraform vs. Puppet

Like Chef, Puppet is also a configuration management tool used to install and manage software on already existing servers. It requires a master server for storing the infrastructure state and the installation of an agent software in the supported servers. So the same advantages of Terraform over Chef applies here as well.

Terraform vs. Ansible

Ansible represents a procedural style of coding. It is a configuration management tool with a changeable infrastructure model. One advantage here is the fact that a big community serves ansible. It is also highly desirable in the job market right now. Ansible does not require running a master server to store the state.

Terraform vs. SaltStack

SaltStack is a configuration management tool; has a declarative style, similar to Terraform. It uses a changeable infrastructure model. It requires the installation of agents and a master server.

Terraform vs. CloudFormation

CloudFormation is similar to Terraform in its declarative style. Like Terraform, it is also a provisioning tool. But, CloudFormation is a non-open-source one; it belongs to AWS services, limiting its scope within the AWS scope.

Why use Terraform?

Terraform is open-source, means you have access to the code to read, debug issues, and contribute to future releases. Terraform gets frequent updates and supports from new providers every day from the large community using it.

Terraform stores state about configuration and managed infrastructure, which is used to map a configuration code to real resources. The state file is stored locally by default, but it can be stored on different backends like AWS S3, Consul, Google Cloud Storage, or PostgreSQL.

HashiCorp created HCL* (HashiCorp Configuration Language) to build a structured configuration language that is human and machine-friendly – and fully JSON compatible, providing simple loops, conditions, giving a lot of power to create a reusable and tested infrastructure. Terraform uses plan command, which means you can review the changes you are about to apply before applying them. It also supports cloud providers other than AWS or Google Cloud.

Reasons to consider Terraform as one of your DevOps tool set;

1. Terraform defines infrastructure in config/code and will enable you to rebuild/change and track changes to infrastructure with ease. Terraform provides a high-level description of infrastructure.
2. Terraform is a sophisticated tool that completely platforms agnostic as well as supports other services.
3. Terraform helps you to implement coding principles like having your code in source control, the ability to write automated tests, etc.
4. Terraform is the best tool for infrastructure management. Many tools have a severe impedance mismatch from trying to wrangle an API designed for configuring management to control an infrastructure environment. Terraform matches correctly with what you require to do- the API aligns with the way you think about infrastructure.
5. Terraform has an active community and is open source, means Terraform is evolving at a much faster rate, releasing updated features more often.
6. Terraform’s speed and operations are exceptional. Its plan command lets you see what changes you’re about to apply before you apply them.

Terraform is a great tool when it comes to DevOps for the reasons mentioned above and more.

One suggestion I would leave you with is, in DevOps, the right tool may not be the right tool industry is leading by or just one tool. Please do read up on any tool before you choose it as your tool. You will have to take an inventory of what your needs are when it comes to IAC, and pick and choose with experimenting on a small scale with available tools. My preference over the last five years has evolved into Terraform and hence the article.

Do you use IAC in your DevOps practice? If so, what is your preferred tool, and why?

Written by Saj Jaffer

Dascase provides critical DevOps-as-a-Service, Infrastructure as a Code, Cloud Migrations, Infrastructure solutions and Digital transformation to high growth companies looking for expert support with DevOps, Kubernetes, cloud security, cloud infrastructure, and CI/CD pipelines. Our managed and consulting services are a more cost-effective option than hiring in-house, and we scale as your team and company grow. Check out some of the use cases, learn how we work with clients, and read more about our Service offering.