Introduction to Infrastructure as Code using Terraform
7 min read

Introduction to Infrastructure as Code using Terraform

Introduction to Infrastructure as Code using Terraform
Ye olde infrastructure days

In the past (and occasionally in the present in some companies), we used to do lots of manual grunt work setting up our infrastructure. A typical approach to launching an infrastructure involved raising tickets to your data center provider and waiting for them to execute your request. A system administrator grabs the ticket and generally uses a management portal of some sort, and starts clicking away at different configuration menus until your infrastructure is deployed and provisioned.

This approach has worked fine for many data centers that didn’t frequently change for a long time. These companies would have virtual machines that stayed up for months or even years that didn’t scale as often.

Since then, infrastructure has transitioned into the cloud with companies like AWS, Azure, Google Cloud, DigitalOcean, and many others, giving us a complete infrastructure as a service platform. Instead of having someone else provision the infrastructure for us, we have all the necessary tools required to deploy our infrastructure in the cloud. Despite having the tools provided by these companies, we still have to rely on manual infrastructure provisioning, which creates room for mistakes and more things to forget.

What is infrastructure as code (Iac), and how can it help you?

Infrastructure as code is the process of defining your infrastructure in code using configuration languages such as YAML, JSON, or, in the case of this series Hashicorp Configuration Language (HCL). It allows you to define your data center’s desired state and overall topology in a definition file, then uses your definition files to feed into software to provision and deploy your infrastructure, giving you very consistent and predictable environments. The benefits of infrastructure as code are many, and there is very little reason not to use it. Here are just a few of the ways Iac can help you.


When you use Iac, you’ve virtually automated your infrastructure. Since you now have a preconfigured definition file, you don’t have the manual grunt work of clicking through an admin interface to provision your infrastructure.


Iac will ensure consistency and make your environments the same every time you deploy a new environment. It also protects you from forgetting things, such as setting up a Security Group or DNS configuration, which is a drawback of manual human work.

Repeatable and Reusable Components

Since everything is in a definition file for each infrastructure piece, Iac gives you a repeatable process with reusable components. Repeatable in the sense that you can now deploy that exact infrastructure on different platforms and environments. Reusability gives you the ability to deploy and reuse the same definition files across multiple project infrastructures. For example, if you have a web server with a specific configuration, you can use that configuration combined with other infrastructure pieces to make your task much more straightforward.

Documented Infrastructure

Using Iac will provide detailed documentation of the architecture used to provision your infrastructure. New and existing team members will benefit from this and easily understand your infrastructure’s setup, allowing them to contribute faster.


Finally, Since your infrastructure is code, you can commit the changes to source control software like Git, giving you the ability to track and version the change history and the evolution of your infrastructure over time. Source control also allows multiple team members to work together on the same infrastructure in a distributed way, and it keeps track of who changed what to the infrastructure.

Types of Iac

Now that we understand what Iac is and why it’s important let’s talk about the two types of Iac configurations. As we’ve mentioned before, Iac uses configuration languages like YAML, JSON, HCL, and others. There are two main types of Iac configuration styles. Declarative and Imperative.


Imperative style is a way of writing configurations for an Iac software using a detailed and procedural set of instructions to provision your infrastructure. It needs to know the steps and the order in which it should create the infrastructure. That’s probably a bit hard to understand, so let me explain it with a pizza example.

If you imperatively tell a system to make a pizza, then this is how it would  look like:

  • Get me the dough
  • Work the dough into a circle
  • Add the sauce
  • Add Mushrooms
  • Add Onions
  • Add bell peppers
  • Add the chicken
  • Add the black olives
  • Add the cheese
  • Preheat the oven
  • Put the pizza in the oven
  • Bake the pizza
  • Declarative

    Software that uses declarative configuration comes preconfigured to perform routine tasks. All you have to do is declare your desired state, and the software will take care of the rest. You don’t have to give it step by step instructions on what it should do since the software already understands how to perform your task and in which order. Let’s once again go back to our pizza example.

    If you declaratively tell a system to make a pizza, then this is how it would look like:

    food pizza "chicken-pizza" {
    	toppings = ["Mushrooms", "Onions", "Bell Peppers", "Black Olives"]

    And that’s all! The system will handle the rest since it already knows how to make a pizza.

    Introducing Terraform

    Phew! Now that we recognize infrastructure as code, let’s finally discuss Terraform, this tutorial’s primary focus. 

    What is Terraform?

    Terraform is an open-source declarative style infrastructure as code software created by HashiCorp. It uses a declarative style syntax known as HashiCorp Configuration Language (HCL). Terraform uses a push-based model to make changes to your infrastructure, which means that Terraform does not require you to install an agent software running on the infrastructure to use it. All you need is the Terraform CLI tool installed on your machine, with the credentials or token of your cloud provider, and you’re good to go. Terraform is not limited to cloud providers only and can also provision on-premises infrastructures like OpenStack and VMware. It can work with Platform as a Service (PaaS) like Heroku, Kubernetes, and AWS Lambda functions. Finally, Terraform works equally well with Software as a Service (SaaS) platforms like DataDog, CDNs such as Fastly, and even Github.


    Terraform is idempotent, meaning when you run a command using Terraform to deploy a piece of infrastructure, it remembers the state. If you try to run the same configuration, it will not make any changes keeping everything in-tact and preventing accidental modifications of your infrastructure. If we reuse our pizza example, suppose you asked for Terraform to make you a pizza, and it does, then you ask it again, it will tell you, “I already gave you a pizza” unless you specify you want a new pizza Terraform won’t make it.

    Terraform Components

    Terraform is comprised of four major components at a high level. Terraform executable, Terraform files,  Terraform plugins, and Terraform state.

    Terraform executable

    The executable is a self-contained CLI application made in Go, and you can download and install it on any operating system (OS). It’s the only thing you need to create and manage Terraform configurations.

    Terraform files

    These are the configuration files that you will create and feed to Terraform. When you make an infrastructure setup, you typically have one or more terraform files inside a directory, which terraform uses to combine and create an infrastructure for you based on those files’ contents.

    Terraform plugins

    Terraform is a single executable that interacts with multiple providers, for instance, AWS, DigitalOcean, and Azure. You can install these providers in the form of plugins that Terraform can use to interact with your infrastructure provider. Plugins make Terraform highly extensible, allowing it to work with any provider.

    Terraform state

    Finally, once Terraform has provisioned your resources, it creates a state file that contains your current infrastructure’s state. Terraform can then keep track of the changes that happen over time. For example, if you have updates to your infrastructure Terraform will compare those changes and apply only the essential differences between your new changes and your current infrastructure state.

    How does Terraform work?

    Terraform has two fundamental pieces that make it work, the core and providers. The core is the part of Terraform that understands your configuration and manages your infrastructure’s state definition files. It handles all lifecycle related management, such as planning creating, updating, as well as destroying your infrastructure. The second part is the providers. Providers are how Terraform connects to the outside world, such as AWS, GCP, DigitalOcean, and Azure.

    Terraform Essential Commands

    There are many built-in commands in Terraform, but these four commands are essential and worth committing to memory. Those commands are, terraform fmt, terraform plan, terraform apply, and terraform destroy.

    The terraform fmt command ensures that your code style does not diverge in time and that it is appropriately formatted. It’s especially useful if your code editor doesn’t support code linting Terraform files.

    The second command, terraform plan is the most crucial among all of Terraform commands. This command checks your infrastructure and figures out what your desired state will look like based on your infrastructure’s current state. It then compiles all this information for you, which you can output to a .tfplan file. The plan will list everything Terraform will create, delete, and update based on what’s already there in your infrastructure, but it doesn’t modify your infrastructure in any way. The plan is just that; it plans out everything before applying those changes.

    Once you’re okay with your plan, the next command is terraform apply. This command will take the plan file that you created using terraform plan and execute it. It will create infrastructure pieces in their proper order based on whichever cloud provider you’re deploying on. Terraform is cloud-agnostic, so it knows how to configure each provider, given that you’ve told Terraform to install that provider’s plugin.

    Lastly, we have terraform destroy, which cleans up everything performed by terraform apply and destroys it safely, bringing us back to our original state.

    Thanks for reading!

    Hang in there, I know the article may seem a bit fragmented, but in part two, we’ll make all this information very clear with hands-on demos.