Terraform and Ansible for the Non-Technical

In this article I provide an overview of Terraform and Ansible for a non-technical Audience. I believe this overview will be useful for technical people as well in case they are new to Terraform and Ansible.

Terraform and Ansible are tools used to provision, configure, maintain and monitor the IT infrastructure needed for developing and deploying your applications.

Before we dive deep it is important to set the context in which these tools operate. So, a bit of background is in order.

Evolving Development Paradigm

The older development paradigm mostly followed some form of waterfall methodology with long development cycles followed by long release processes. They were constrained by specific release windows which were few and far between. It is not uncommon to see some legacy firms still having 4 releases a year, one per quarter!!!

The development paradigm is now shifting to Agile. Agile of course comes in many flavors, organizations alter the working framework to suit their needs while adhering to the manifesto to some degree.

The implication to the Infrastructure world is that the older paradigm of long cycles is now getting changed to shorter and shorter cycles. What was once a release every quarter is now a release a day cadence.

You Built it, You Fix it

Another paradigm shift is being observed in the support model. In the older paradigm, the application support followed a tiered model. There was level 0, level 1, level 2 support for Applications in production. The teams providing production support were different from the development teams.

This meant a lot of handoffs and worse, the code is filled with hotfix patches made by someone who did not design or build it.

In the new paradigm the model is you Built it, you Fix it In this paradigm, the development team that builds the application also manages the production issues. The implication to infrastructure teams is that the development teams prefer more control and ownership of the infrastructure their application runs on, i.e. Self-serve.

IaC — Infrastructure as Code

The traditional approach to provisioning has been through manual configurations based on some sort of a ticketing system with a lot of point and clicks. This lead to a lot of overhead like large Infrastructure Services teams, long deployment cycles, fewer releases, increased dependencies between teams.

Source: Terraform.io

IaC aims to address these and other problems by removing the manual configuration, monitoring and provisioning and replacing it with code. This means that the infrastructure team develops scripts that are executed like code and can be version controlled, deployed to multiple environments, peer reviewed, shared, forked and so on.

Terraform and Ansible

At a high level, think of Terraform and Ansible as tools that allow you to provide IaC for your organization. Terraform and Ansible have features that allow you to write all your infrastructure needs in a human readable code form.

For the rest of the article I will use Terraform as an example as both Terraform and Ansible are quite similar. At the end of the article, however, I will highlight the major differences.

Terraform

Provisioning on any project is split into 2 parts, Day 1 and Day 2-Day n. Day 1 provisioning involves the creation of all the infrastructure and configuring them from the ground up. This is usually the case at project start.

This requires some level of understanding of the project infrastructure requirements, of course these requirements are not set in stone and can be scaled up or down during the course of the project i.e. Day2 onwards.

Terraform has 4 major steps/commands that are relevant during both Day 1 and Day2

1. Refresh — In this step Terraform evaluates the current state of your infrastructure world and the target state of the infrastructure world as defined in the latest version of your infrastructure provisioning code. Example — It is Day1 and you would like to provision 3 AWS EC2 Resources. Refresh would find that there are 0 instances running (it is Day 1) and Terraform has been asked to create 3 instances of EC2
2. Plan — In this step Terraform creates a graph that allows it to formulate the steps needed to be taken and in what sequence to make the target state match what is described in the provisioning code.Continuing our example, Terraform plans to create 3 EC2 Resources
3. Apply — In this step Terraform executes the plan i.e. provisions and configures the EC2 Resources as per the plan. Terraform provisions 3 EC2 Resources
4. Destroy — If for some reason you would want to bring down the infrastructure and de-allocate all the resources, then it can be done using the Destroy command. (Note that Destroy is a special type of apply. One could update the provisioning code to 0 instances and run through Refresh->Plan->Apply to the same effect.)

Some Useful Jargon

In Terraform parlance some repeatedly used jargon is Providers and Resources.Providers that are supported by Terraform are grouped into three broad categories.

1. IaaS — Infrastructure as a Service Ex — VmWare, Azure, AWS etc.
2. PaaS — Platform as a Service Ex — Heroku, Amazon lambda etc.
3. SaaS — Software as a Service Ex — Datadog, Github teams etc.

In the above example, I used a very simple provisioning use case with a single provider i.e. AWS and a single resource i.e. EC2.

Terraform supports hundreds of providers and thousands of resources. Being an open source project the list keeps on changing (mostly growing). Not to be too evangelical but Terraform can move your organization towards a Cloud services Provider Agnostic Model and enable infrastructure that is largely Self-Serve.

Ansible

Red Hat Ansible is an open source automation tool. The use cases for Ansible goes beyond just provisioning to other cases like Configuration Management, Application Deployment, Security Automation, Orchestration.

Long story short, from a features comparison perspective everything that Terraform can do Ansible can do it too. Then this brings us to the important question.

Terraform or Ansible?

It depends (Like all good answers) a lot on your particular use case. It is more common to use both than either one of them. The table below summarizes the difference that will help clarify which tool is applicable in what use case.

On a side note, I think for legacy organizations there are several pre-considerations before they even contemplate the choices like Terraform or Ansible? The implications of the emergence of IaC to legacy organizations is massive. Most of them would have to re-visit their IT infrastructure strategy and undertake large transformations to enable the Dev Teams compete in the rapidly changing world with greater Agility.

I hope this short article was able to demystify these tools. Of course, I have only scratched the surface. To learn more I would recommend the source documentation of Terraform and Ansible.