Section 1: The Basics
Section 1 aims to introduce you to the basics of Infrastructure as Code (IaC), comparing other IaC options such as ARM templates and AWS CloudFormation to Terraform and how Terraform can be used to provision infrastructure. You will also get an understanding of how Terraform can be set up on a local system.
The following chapters will be covered under this section:
- Chapter 1, Getting to Know IaC
- Chapter 2, Terraform Installation Guide
Chapter 1: Getting to Know IaC
In this chapter, we are going to discuss what Infrastructure as Code (IaC) is in detail. We will be discussing the benefits of using IaC. Furthermore, we will start describing the basics of Terraform, and then undertake a comparison of Terraform with other available IaC options, including AWS CloudFormation, Azure Resource Manager (ARM), and Google Cloud Deployment Manager. Moving on, we will then discuss Terraform architecture.
Throughout this chapter, we will be focusing on Terraform for major cloud providers, including GCP, AWS, and Azure. The whole chapter will help you in terms of achieving a fair understanding of Terraform (IaC) and how you can overcome the old lego system of executing manual changes to your environment. This will help you get an idea of how you can start using Terraform for infrastructure automation in your organization.
The following topics will be covered in this chapter:
- Introduction to IaC
- Advantages of IaC
- Introduction to Terraform
- A comparison with other IaC
- An understanding of Terraform architecture
Technical requirements
To follow along with this chapter, you need to have a basic knowledge of different IaC options, including ARM templates and AWS CloudFormation, while a basic knowledge of major cloud providers, such as GCP, AWS, and Azure, will be beneficial.
Introduction to IaC
Before learning about Terraform, let's try to understand what it basically means for us and how it helps make users' lives easier in the IT industry. The first thing that always comes to consumers' minds is that when they need an IT infrastructure, for example, if they want a virtual machine, they need to raise a ticket on some ticket portal such as ServiceNow, and someone from the backend would log in to that ticketing portal and take that ticket from the queue and deploy the virtual machine for the consumer, either in VMware or a HyperV environment through the management portal using some click jobs. That is the traditional approach for infrastructure deployment, which is somewhat fine if they need to manage infrastructure in their private data center and there is very little possibility of performing scaling of those deployed resources, which means once it gets provisioned, after that no one is requesting further changes to the created resource.
In all these cases, it is fine if they easily go ahead and perform all the operations manually but what about if they need to deploy a very large infrastructure consisting of more repeatable work in the cloud? Then it would be a really tedious job for the administrator to provision those resources manually and also it is a very time-consuming job for them. So, to overcome this challenging situation, most cloud vendors have come up with an approach of IaC, which is mostly an API-driven approach. Most cloud vendors have published APIs for all their resources. Using that API, we can easily get the resource deployed in the cloud.
Nowadays, as most customers are moving toward the cloud, and as we all know, cloud platforms provide us with more elasticity and scalability in terms of their infrastructure, this means you can easily utilize the resources and pay for what you use; you don't need to pay anything extra. Just think down the line of an administrator needing to perform the scaling up and down of resources and how difficult it would be for them. Let's suppose there are 1,000 resources that need to be scaled up during the day and scaled down at night.
In this case, consumers need to raise 1,000 tickets for performing the scale-up and again 1,000 more tickets for scaling down, which means by the end of the day, the system administrator who is managing the infrastructure will get flooded with so many requests and it would be really impossible for them to handle this. So, here we have something called IaC, which is a way of deploying or managing the infrastructure in an automated way. All the resources that need to be managed will be defined in code format and we can keep that code in any source control repository, such as GitHub or Bitbucket. Later, we can apply a DevOps approach to manage our infrastructure easily. There are many advantages of using IaC; we are going to discuss a few of them.
Advantages of IaC
Let's discuss a few of the advantages of using IaC.
Simple and speedy
Using IaC, you would able to spin up a complete infrastructure architecture by simply running a script.
Suppose you need to deploy infrastructure in multiple environments, such as development, test, preproduction, and production. It would be very easy for you to provision it with just a single click. Not only this, but say you need to deploy the same sort of infrastructure environments in other regions where your cloud provider supports backup and disaster recovery.
You can do all this by writing simple lines of code.
Configuration consistency
The classical approach of infrastructure deployment is very ugly because the infrastructure is provisioned and managed using a manual approach that helps to maintain some consistency in the infrastructure deployment process. But it always introduces human error, which makes it difficult to perform any sort of debugging.
IaC standardizes the process of building and managing the infrastructure so that the possibility of any errors or deviations is reduced. Definitely, this will decrease any incompatibility issues with the infrastructure and it will help you to run your application smoothly.
Risk minimization
When we were managing infrastructure manually, it was observed that only a handful of Subject Matter Experts (SMEs) knew how to do it and the rest of the team members remained blank, which introduces dependency and security risks for the organization. Just think of a situation where the person who is responsible for managing the complete infrastructure leaves the organization; that means whatever they knew they might not have shared with others or they may not have updated the documents. At the end of the day, risk has been introduced to the organization because that employee is leaving. Many times, in such cases, the organization needs to undergo some reverse engineering to fix any issues.
This challenging situation can be controlled by using IaC for the infrastructure. IaC will not only automate the process, but it also serves as a form of documentation for your infrastructure and provides insurance to the company in cases where employees leave the company with institutional knowledge. As you know, we generally keep IaC to source control tools such as Azure Repos or GitHub. So, if anyone makes any configuration changes to the infrastructure, they will get recorded in the source control repository. So, if anyone leaves or goes on vacation, it won't impact the manageability of the infrastructure because the version control tool will have kept track of the changes that have been performed on the inf...
