Having been at Hippo for over a year now, I’ve been lucky enough to be exposed to a number of interesting and engaging projects. One of which makes great use of Terraform, especially when it comes to optimising for efficiency.
What is Terraform?
“Terraform is an infrastructure as code tool that lets you build, change, and version infrastructure safely and efficiently. This includes low-level components like compute instances, storage, and networking; and high-level components like DNS entries and SaaS features.”
HashiCorp Developer
This means that using some configuration and a CLI (Command Line Interface), you can deploy and, once it’s no longer needed, tear down an entire infrastructure for your project!
The technology has been around for some time, but for me, this was the first time I got to experience it.
Life before Terraform
Before my life at Hippo and Terraform, I would have to either ask the infrastructure team to create what I needed or manually add it myself. This in itself is not a problem but it takes time, and if you multiply the time by the number of environments you need (live, test, dev etc..) then it can become a lot.
Generally, our environments were long-standing so once we had it set up, we had no reason to tear it down but looking back now I can definitely say that I would have used Terraform in some projects.
One example would be when I needed a short-lived upgrade site for testing against third parties, which took the best part of a day to create the infrastructure and deploy the code to it. This also had to be done every 6 months.
If I had been using Terraform, then it would have meant I could build and tear down exactly when I needed it with very little effort and in a fraction of the time.
Using Terraform
On a particular project at Hippo, Terraform was already implemented but I could immediately see the huge benefits it had added. Multiple environments are being used and one was created just for prototyping.
The prototyping environment was built quickly by adding a trivial amount of configuration and the website and all its infrastructure was up and running in less than a few hours (most of that time was spent end-to-end testing).
In contrast, imagine having to build the infrastructure manually, set up web services, cloud functions, databases and more. That alone would have been far more time consuming, and that’s before adding the code deployment on top.
The best part, I can tear it all down again easily when it’s no longer needed. Saving resources and costs.
Terraform in action
Configuration
A configuration file (main.tf) consists of any configuration needed for your provider. For example, if you’re using Azure it may start to look like this:
This is just the start, the next phase would be to configure what web services and databases you wish to deploy. The below screenshot is from Microsoft and shows a web app configuration for Azure:
CLI Commands
Once you have setup configurations, you can use the CLI commands.
All commands can be found here https://developer.hashicorp.com/terraform/cli/commands but, for the purpose of this piece, I will list the most common ones below:
- Terraform plan – show changes required by the current configuration. This is very useful because you can see if the current configuration will work and what exactly is going to change. You would typically use this before Terraform apply.
- Terraform apply – this will build and deploy your infrastructure based on your configuration.
- Terraform destroy – this will destroy (aka tear down) all the infrastructure that is configured in your configuration files.
Pros & Cons
Pros:
- Quick infrastructure creation & deletion. Add it to a CI/CD pipeline for even more ease.
- Consistent builds – once it’s in place, no need to think about it.
- Great for large projects with many web services and environments to create.
- Less time spent setting up and tearing down infrastructure.
Cons:
- Lots of upfront cost to learning Terraform, its configurations and the actual setup of your infrastructure.
I believe Terraform is a remarkable technology, and for anything bigger than a small/prototype project it would be worth the time investment in getting it up and running. Add it to a CI/CD pipeline and you will have an incredibly efficient setup.
From a clients perspective, this would mean less time spent building environments & less time spent in potential disaster recovery as you can get it running again no time at all. Win win.
