Unlocking IaC Part 1: WTF Are We Even Doing Here?

What are we talking about here?

A pet peeve of mine when I was new to tech, or even today when new tech finds its way to me, is when a tutorial picks up in the middle of the knowledge journey. It’s no fault of the author; many times, tutorials are simply not aimed at the complete novice - the tutorial author created it because they learned something useful or cool and want to share that knowledge with like-minded people.

What if, however, you don't have the fundamental questions answered, like "why" does this tech exist? How does it help me? Why should I care to learn it? I will review those questions quickly below; if you already know the "why" for Terraform, then skip this section.

Why Terraform?

I am assuming that if you are reading this, you have either installed a server OS on a piece of hardware or have manually created servers in the cloud at some point. You have the experience of clicking from screen to screen, answering questions, choosing options, and filling in the blanks as needed to create a server in the cloud. Then you have moved on and created other resources in the cloud like load balancers, storage, subnets, etc.--but again, clicking and typing your way through the process. That’s the manual version of Terraform. It is very slow, and because we are human, we are prone to typo or misconfiguration errors.

Terraform exists to:

1. Standardize this creation process through code and,
2. To accelerate both the CREATION and the DESTRUCTION of cloud services

What would take 40 minutes of manual clicking and typing can be done in 3 minutes. The end result not only gets done faster, but it’s always the same! If you work with a team, you can share this code (aka IaC or Infrastructure as Code) with them through services like GitHub. Sharing, working collaboratively, refining the code, and re-using it to focus on consistent, secure cloud services. Sounds nice, right?

Intro to Terraform

Terraform here, Terraform there, everywhere engineers look in the modern job landscape, you will find the need for Terraform.

There's a good reason for it. Although there are other IaC tools (AWS CloudFormation & Pulumi, for instance), Terraform is and has been the dominant tool because it is cloud agnostic, declarative, and has a strong ecosystem and community support.

Don't know what most of that means? You are in the right place!

Starting from the top:

• IaC: Infrastructure as code - this is the concept of turning your manual efforts of building infrastructure (virtual machines, load balancers, user identities/roles, DNS, etc.) into code. This code can be built once and re-used many times. It results in a uniform, consistent deployment of infrastructure. It can also be stored in Git platforms like Github for simplified management of the code itself.

• Cloud Agnostic: Within Terraform, there is the concept of a "provider,” A Terraform provider is all of the pieces of code needed to interact with a specific cloud service provider (like AWS). The Terraform provider is included in the code (at the top of your file) and is referenced throughout your IaC configuration. It’s how Terraform is aware of the little nuances within the cloud provider, like how in AWS, a virtual machine is an "EC2" instance, and in Google Cloud, it’s a "Compute Engine.”

• Declarative: This is important, so try to lock this away somewhere. Terraform is a declarative language, meaning with it, you define the end-state of your infrastructure, and the code figures out how to make it happen. You don't have to define every single step to build an EC2 instance in AWS. Instead, you define the outcome. The other model is an Imperative language, which requires the user to define, in order, the steps needed to create the EC2 instance.

Alright, now you have the basic pieces of Terraform in your head. Let’s dive into the next layer of Terraform knowledge needed to get up and running.

Terraform (a deeper dive)

Once the initial learning and configuration occur, Terraform is a pretty straightforward technology to work with. The challenge for me, and likely other people, was identifying the key components that enabled Terraform to work its magic while also understanding their purpose. Identifying key components without also knowing their purpose will result in confusion and frustration further down the line when your code requires debugging.

Below are--in my opinion--the basic pieces of Terraform knowledge needed.

• Terraform Configuration: The Terraform configuration is the actual files and file structure where the Terraform code exists. Terraform files end in ".tf" file extension. Although you can name these files almost anything you want, a common method is to start with "main.tf" and then add other files as needed with descriptive titles (like "variables.tf"). These Terraform files are filled with HashiCorp Configuration Language (HCL) which is what most people refer to simply as "Terraform" when they see it.
• Terraform Provider: As mentioned above, Terraform providers are packaged code that gives Terraform its ability to interact with different cloud services. There are providers for AWS, Azure, and Google Cloud, as well as other services like Okta, VMware vSphere, Kubernetes, Github, MySQL, Helm, and many many others. A Terraform provider is (almost) always included in the top part of your Terraform configuration before the rest of the code.
• Resource: This is a fundamental component of Terraform code. A resource represents a piece of cloud infrastructure, like a virtual machine, for instance. Within this resource is where you would define the qualities of this cloud infrastructure. For example, continuing with the virtual machine instance, inside of the resource is where we would define the amount of attached storage, the quantity of RAM, add a descriptive name, and other items needed to provision this cloud infrastructure.
• State: Terraform keeps a record of the infrastructure it has provisioned in a special file called a "state file" (this is usually named terraform.tfstate). This allows Terraform to track resources and prevent conflicts and inconsistencies. It helps map real-world resources to your configuration, keep track of metadata, and improve performance for larger infrastructures. This file will be automatically created within the directory where Terraform is running.
• Terraform CLI: Once you have created your Terraform configuration to build your cloud infrastructure, you still need to take action on this configuration. The Terraform CLI is the tool that enables you to take action. The Terraform CLI uses commands like terraform init, terraform apply, and terraform destroy  to initialize, create, and tear down infrastructure, respectively.
• Plan: Despite our best efforts, we’re human, and we will make mistakes. It could be something simple like syntax, missing a bracket, or misspelling a resource. Or it could be something like using destructive commands without realizing it. Before making any changes to infrastructure, Terraform computes a detailed plan of what will happen when you apply your configuration. The output of this process is a line-by-line report (presented on the command line) of what will be changed. It’s vital that you review this in detail prior to applying the Terraform code.
• Variables: If you are familiar with the concept of a variable in programming or development languages, then bring that with you here. These allow for the parameterization of Terraform configurations. They make configurations more flexible and can be set in various ways, including from a file, command line, or environment variables.
• Outputs: Using Outputs in your Terraform code can give you some feedback after your code has run. Outputs are defined like a Variable, but instead of accepting data as part of the running-of-the-code it collects then outputs data from the cloud infrastructure that was just build This can be useful to retrieve IPs, DNS names, or any other attributes of the infrastructure that are needed.

If you have made it here, be sure to check out Part 2 (coming soon) as we take this abstract knowledge and turn it into action by setting up your Windows machine with all the pieces and parts needed to build with Terraform in AWS.