In this Infrastructure as Code 101, I will explain the foundational concept behind Infrastructure as Code, its advantages, and I will also elaborate on why organizations are increasingly looking for professionals who are skilled in the technologies and tools that enable this.
Firstly, it’s important to understand that there are different approaches to Infrastructure as Code (IaC), depending on the type of infrastructure that’s being managed:
- On one hand, for virtualized/cloud infrastructure: Considering that in this model, it’s possible to create or destroy resources (for example, virtual machines) as needed or no longer needed, there are tools that specialize in automating this task (we’ll explain the necessity and the reason behind this later on). Some of the tools that have gained significant traction in recent years for this type of infrastructure (also known as immutable infrastructure) are Terraform (vendor-agnostic, by HashiCorp) and CloudFormation (by AWS).
- On the other hand, for physical infrastructure (such as servers, network devices, and others, also known as mutable infrastructure): since in this case, it’s not possible to create or destroy resources (well, destruction would be possible but it would involve throwing a Router from a ninth floor 😜), the tools specialize more in implementing configuration changes on the devices. Some of the tools that have earned their deserved place in this field are Ansible and Puppet.
A common question that often arises is whether Ansible is better than Terraform, or vice versa. Understanding the previous points, it’s possible to answer that each tool is very good in its specific field of action: on one hand, Ansible is a Config-Management tool, while Terraform is for creating/destroying virtualized resources. Considering this, it’s easy to see that they complement each other quite well: starting with Terraform for deploying resources and then moving on to Ansible in a second stage for their configuration (as one of the many possible scenarios, which can also involve variations with other technologies).
🎥 I invite you to watch the following video (although it’s in Spanish, you’ll find captions available), where I provide a bit more context about what was mentioned earlier and give a brief introduction to the benefits that will be detailed below:
Taking the above into account, why are companies increasingly adopting IaC? Why is it becoming more and more relevant for professionals to master these tools?
I’ll try to answer the above questions through the following reasons:
Automation and Time Savings
While in a cloud environment, having resources available almost immediately through a service model significantly speeds up infrastructure deployment (compared to starting from scratch with physical infrastructure), this setup also involves a set of repetitive tasks. These tasks conventionally should be performed through the dashboard to power on/off instances, connect services together, enable connectivity between them, and more. Since cloud providers charge based on service usage, imagine having to perform these tasks regularly to optimize costs and avoid being billed for times when a certain service isn’t used. IaC significantly streamlines “ClickOps”, or in other words, the need to perform countless clicks on the dashboard to manage these resources on a daily basis.
Repeatability
As the size of the infrastructure scales up, there is usually a desire to maintain a certain level of consistency in its configuration for various reasons: internal compliance within the company, security, best practices, ensuring the presence of previously tested configurations, and more.
Defining infrastructure as code enables the reuse of configuration modules so that all resources of the same type are configured in the same manner!
Imperative vs. Declarative Configuration
Tools like Terraform introduce a shift in the paradigm of configuring systems, moving away from needing to know all 146 CLI commands in a specific order to go from point A to point B (which is traditionally known as imperative configuration). Instead, what Terraform (and other tools) allow is to define the configuration of resources in an declarative manner. What does this mean?
As we can see in the previous image, if we imagine that our friend who gets the “lightbulb moment” is Terraform, it’s evident that when comparing the current state of the infrastructure with the desired future state (described as code in a configuration/deployment file), Terraform has the intelligence to detect what change needs to be made to go from point A to point B, along with the necessary sequence of steps.
Version control
Imagine the following scenario: A configuration file is deployed, and an incorrect parameter hidden deep within the code causes a critical service for the company to become unavailable. What was the cause? How can it be resolved as quickly as possible?
Fortunately for us, since we’re dealing with code, a version control tool like Git is undoubtedly involved. To identify the change that affected the service, it would be sufficient to review previous commits and potentially roll back to the appropriate commit to fix the issue, and then redeploy. No need to identify a specific command line! 😁
Change Control and Collaboration
This refers to maintaining an organized and systematic record of all modifications made to the code that describes the configuration of the infrastructure.
Simultaneously, various mechanisms exist that enable the combination of changes made by different individuals in the same code. When multiple people collaborate on the same infrastructure project, it’s crucial to ensure that their changes are compatible. Moreover, when applying changes, it’s vital to avoid overwriting each other’s work. (Imagine accidentally deleting a server because you didn’t have the updated version of the code someone else was working on in parallel 😱)
The advantage of having a change control and merge approval system in IaC lies in secure and orderly collaboration. It allows multiple people to work on the same project without unintentionally overwriting each other’s work. Before changes are applied to the actual infrastructure, there’s the opportunity to subject them to a review and testing process. This reduces the risk of errors and botched deployments.
Did you find this information useful? Do you know any other advantages you’d like to share? I’ll be reading your comments 🤓👇🏻