All About Terraform: Laying Out the Basics
I’m sure that most of you have already heard about Terraform. It’s already widely used by people working in the IT world, especially in the infrastructure division. In fact, we have been using Terraform for quite a long time in our DevOps team at HARA. You can check out Terraform’s page here.
But what is Terraform exactly? What are its benefits compared to the old-style of infrastructure provisioning? Why is it called an Infrastructure-as-Code (IaC) software? These are the questions we’re going to explore further in this blog post.
What is Terraform?
Terraform is a software that enables you to define your whole infrastructure using code, hence it’s called Infrastructure-as-Code (IaC). You can build new infrastructure, make changes and improvements, version your code to be shared and reviewed amongst team members, and even reproduce your code to be used in the future.
With the rise of Pulumi earlier this year, we decided to compare these two IaC tools to see which one really suits our needs the best. Based on our experience, we found that Terraform is more of a declarative programming, where it focuses on creating the logic without describing its flow.
In contrast, Pulumi is more of an imperative programming, since it uses some of the existing popular languages like JavaScript, TypeScript, and Python, which is good if you’re really familiar with the programming languages it supports and don’t have time to learn another DSL in the form of HCL. However, Pulumi is relatively new to the IaC world, so there is little to no documentation and tutorials except from their own website, making it difficult to learn how to work with. You can check our review about Pulumi here!
I’ll give you a scenario in which Terraform excels. In the early days of infrastructure provisioning, all of the tasks could be considered to be done manually. Let’s say someone from the finance division requests to launch a new server for their finance software. Okay, that sounds like a piece of cake for you.
You go to your console, create a new VM or instance, specify the CPU and RAM (or instance type if you are in cloud), specify the disk space, specify the network, click-click-click, aaaand… done! 1 server, at your service.
Now let’s change the scenario a bit: what if the back-end team requests to launch 100 new servers in a day because they needed to start developing a new app right away? And it’s already 4 PM, an hour before you wanted to go home.
Key Features of Terraform
So, you heard the case above. It’s impossible to complete the task on time unless your team consists of more than 20 people who are all still in the mood to start an additional task so late in the day. However, by using Terraform, you can accomplish the task with only 1 person. How you might ask. We’ll break down some of its key features.
Infrastructure as Code
Infrastructure is described in a high-level configuration language. It’s usually defined in a human-readable HashiCorp Configuration Language (HCL), although you could use JSON as well. As such, you are able to version, share, and even re-use your infrastructure with some modifications in the future. In the example below, you can see a snippet of our code to create a new Security Group on AWS.
So, we are creating a new AWS Security Group resource named “dimas_sg”, with the name tag on AWS “dimas_secgroup”, inside a VPC identified with a reference to another AWS VPC resource “dimas_vpc”, and with some inbound/outbound rules.
Versioning
Taking a key word from the first point, being able to version all changes is essential in terms of infrastructure modifications. Have you ever been in a situation where, after a long-planned vacation, you come back to the office and there are 7219305 changes that have been made to your infrastructure by your colleagues, and you have no idea what has changed?
Say no more.
Since it is completely written in code, you can use any CI/CD tool deployed in your infrastructure to version all changes that have been made to the Terraform code, thus making it easier to track.
Cloud Agnostic
Terraform is cloud agnostic, or in other words, not specific to a cloud provider. This means that you can use Terraform on basically all cloud providers. Terraform gives you a list of different providers to choose. For example, you can run Terraform on Azure, AWS, and AliCloud.
Plans
Terraform will provide you with a ‘plan’ on what will your code do. This way, you can avoid any unplanned changes to your infrastructure. After you finished your code, try hitting terraform plan and this will come out.
Since the example above builds everything from scratch, none of them were changed or destroyed.
Terraform at HARA
We have been using Terraform at HARA for quite long time. 95% of our infrastructure, from different divisions, were provisioned using Terraform, and we are planning to keep using it in the near future.
We keep the structure itself very simple. We mainly use main.tf, variables.tf, output.tf, and backend.tf as the core files. Since we primarily use AWS as our preferred cloud service, we also have separated .tf files based on each of AWS services (e.g. route53.tf) so it will be easier to track changes.
We fully utilize the module function here to maximize the components’ reusability, and to keep our code neat. We use both our own created modules and modules that are taken from GitHub. In the context of modularity, we also keep the .tfstate files separated, so that when we make some changes on a project, which will trigger changes on the .tfstate file, it will not affect any other projects.
We use multiple providers for a single project. The reason behind this is that we need to use multiple credentials (in this case AWS credentials) for some resources that span across multiple AWS accounts. There is a default one, and some others that we need to specify on the resource using an alias like below.
As for the current state, we fully run these Terraform codes in our local. Since our DevOps team consists of more than one engineer, there is a large chance that there will be a disparity when one of us makes some changes to the Terraform, while someone else makes different changes as well. In the future, we are planning to fully utilize our CI/CD tools to ensure that the Terraform code would only be run on the CI/CD agent, eliminating constant code overlap.
Conclusion
In our experience, with all of the features offered, Terraform is an important tools in the HARA environment due to its capabilities of orchestrating our infrastructure from zero up until now. We did once think about switching over to Pulumi, but considering it is still a young piece of software and being an imperative programming rather than a declarative programming, we decided to stick with Terraform instead.
We highly recommend you to try out this tool, as we believe that there is still so much more to come from their developers in the future that’ll give us additional features in terms of orchestrating.
This was the first issue of All About Terraform on HARA. Stay tuned to our publication because we will be writing about more advanced Terraform applications in our environment going forward. Until next time!
Join our community on Telegram!
Learn more about HARA
- Visit the HARA website
- Read our White Paper
- Join our Telegram Community
- Follow our Social Media
Facebook, Twitter, Instagram, Medium & LinkedIn
