Repeatability, simplicity, and traceability have emerged as the core pillars (from a coding perspective) for many organizations. Application code is stored in Git or SVN and code reviews are performed through Crucible or in build Pull Requests. Automated deployments help developers to move software and features quickly, thereby delivering additional value to customers.
Somehow, for the longest time, infrastructure was never made a part of this practice and servers were managed manually in the data centers. But then, configuration management and Infrastructure as Code (Iac) was introduced.
Today, most of the infrastructure is hosted in data centers which are either on-premise or are owned by cloud providers such as Amazon AWS, Google Cloud Provider or Microsoft Azure. As we launch new infrastructure, there’s also a behind-the-scenes interaction with robust APIs of each platform. This paves the way for new approaches and innovation. Infrastructure can be deployed and configured through API calls, which provide a great opportunity for Infrastructure as Code (IaC) tools like Terraform, CloudFormation, and Pulumi.
What is Infrastructure as Code (IaC)?
Now, to understand how the infrastructure is managed by organizations, let’s take a deep dive about what exactly we mean by Infrastructure as Code.
Just as we check our application code into Git repos, which serves as the source of truth for all things, we can also describe the shape and characteristics of our cloud infrastructure using code. In Terraform, this means writing HCL (HashiCorp Configuration Language) and checking that code into source control.
When infrastructure changes are desired, one simply opens the Pull Request to a “Terraform” Git repo. It goes through the review process, and any changes are eventually applied to the cloud platform(s) of your choice.
You might wonder how a tool like Terraform keeps track of what it manages. How does it prevent multiple engineers from applying their changes at the same time?
This is where we have the concept of State Locking in Terraform, when multiple engineers are working on code and committing the code simultaneously. To prevent all of them from applying changes at the same time, one might use Terraform DynamoDB state locking, which simply uses DynamoDB as a locking mechanism.
What problems does Infrastructure as Code solve?
Using a tool like Terraform, in combination with version control, we’re able to track each change that gets made to our infrastructure. Previously, before Infrastructure as Code (IaC), we’d frequently use configuration management tools such as Puppet or Ansible and bend it to solve problems it wasn’t best equipped to solve.
In today’s world, new services need to be launched rapidly, and the duration between launching the first environment and production is reducing more and more. In order for DevOps to scale, we need tools that provide us with repeatable, scalable, and transparent ways of managing our cloud infrastructure. Standing up a second environment should be a matter of copying a variable’s file, tweaking it slightly, and then deploying it. This greatly contrasts with the old way of doing things: going through the console, clicking around, and hoping you didn’t miss anything while configuring resources. Infrastructure as Code (IaC)) is a great way to make managing distributed and complex infrastructure sane.