Beginners' quickstart guide to using Terraform. Learn the basics and get started with this powerful tool for automated infrastructure management.
What is Terraform and Why Is It Used?
Get the simplest explanation of Terraform on AWS. Understand its benefits and how it revolutionizes infrastructure management in cloud environments.
Author: Alfredo Espejel, Cloud Infrastructure Lead
Although it has just recently reached its first “stable version”, Terraform is a tool considered to be mature and has been used for years by many companies to deploy infrastructure in the cloud.
There are many complete articles on getting started with Terraform; one of the best (and usually up-to-date) being the introductory documentation on the Terraform website itself. So, we are not going to dwell too much in this article on what it is per se, but rather we are going to highlight some of the strengths of Terraform, why we like it at StratusGrid, and why it is necessary to use an Infrastructure as Code (IaC) tool.
Some Things That Characterize Terraform
IaC offers us a high-level language with which to declare our infrastructure so that we can version and reuse it. Thanks to this type of tool, one goes from manual resource management to “infrastructure programming,” which is much less prone to human error.
At the end of the day, if you keep repeating the same thing over and over, eventually you are going to make a mistake, or the results are not going to be perfectly homogeneous. Having your infrastructure established as code prevents this because you just need to execute the command to have your infrastructure deployed, no matter how complex it is.
For example, if we had to deploy 100 instances with the same configuration, we would most likely fail to create some of them (just imagine yourself creating 100 resources involving clicking on multiple checkboxes, naming them with a pattern, etc. Personally, I would fail a couple of times for sure during the process, missing to check a checkbox or skipping an iteration in the name of the resource). With Terraform this is much less likely to happen because you are able to make a configuration and deploy that configured resource 100 times with a loop. If we create a specific configuration for an environment, using best practices, parameterizing values with variables, etc. doing this same thing for another environment would be easy because we would only need to change the values of the variables accordingly.
One of the main features of Terraform is that it is declarative. Is this good or bad? What is declarative?
Regarding this, there are several programming paradigms that allow us to classify what a programming language is like based on some of its characteristics. So, limiting ourselves to what interests us in this blog post, a programming language can be declarative or imperative.
Depending on how familiar you are with the world of development, the differences between declarative and imperative can be fuzzy, but for those who are new here I will try to give an example related to one of the things I like most in the world, a meal:
I go to a fast-food restaurant and order a hamburger in each form (Declarative and Imperative):
Declarative: hello (world), I would like a hamburger, with cheese, onion, and pickles.
Imperative: hello (world), I would like you to mince 150g of beef, two times, heat a frying pan with a few drops of oil, and put the meat in the shape of a disc of about 12 cm in diameter in the pan at a constant temperature of… you get the idea, right? (It would seem asking imperatively in the real world sounds pretty pointless, agree?).
For infrastructure-as-code, using a declarative language is, in my opinion, an advantage. We can ask or declare resources as if they were an item from a restaurant menu, without worrying to a great extent about what has to happen so that we receive what we want. If a resource is correctly declared in our configuration, after executing Terraform, that resource will be created as we have described it (with our preference of onion, cheese, pickles, etc.). If later we delete it from our configuration, after executing Terraform the resource will be deleted from the infrastructure. In other words, whatever is in our configuration is going to translate into infrastructure. If we add things, infrastructure will be added - if we delete things, infrastructure will be deleted.
Being declarative also has drawbacks (which will be covered in a future post) although in my opinion, and based on my personal experiences with Terraform, the fact is declarative is still more positive than negative.
To end this point, I will leave you with a link to the Wikipedia description of what declarative language is , as well as this other post talking about this topic centered on Terraform, CloudFormation, and then CDK, which is also very interesting to me.
When we are going to deploy resources such as an instance in a specific VPC, it seems obvious that we have to create the VPC before creating the instance. Unfortunately, when we have to create many different resources it is very likely that we will fail with the correct order to deploy them on the first try. Terraform manages both implicit and explicit dependencies (we'll cover this in future posts as well), making it easier to deploy resources in the correct order.
Terraform is licensed as Mozilla Public License v2.0 and being open source allows us to contribute to and extend it, as well as use it for free.
Terraform has dramatically impacted the cloud industry, making it much easier to manage infrastructure. If you want to know more about Terraform, Stay tuned for Part 2 - a Quickstart Guide to Using Terraform!