Infrastructure as code is expanding rapidly as a strategy to manage your application’s infrastructure. If you’re just getting started learning any big cloud provider, more likely than not you’ve visited their cloud user interface. For a company like AWS, developers use the sleek AWS Console to interact with their cloud infrastructure. This includes creating resources, deploying applications, and monitoring their health.
In the early days of cloud computing, it was common for developers to spend hours of their day in the console. As the size of applications has grown, unfortunately, so has the time spent to administer them.
Infrastructure as code is a means to solve this exact problems, and provide many more benefits in the process.
In this article, we’re going to explore what Infrastructure as Code (IaC) is, why its beneficial, and why you should start using it.
What is Infrastructure as Code?
Infrastructure as code, sometimes referred to as its shorthand IaC, is the process managing your cloud infrastructure by writing code as opposed to manually through a user interface. This is different from Command Line Interface tools like the AWS CLI that allow developers to interact with the cloud through their terminal.
The major cloud players (Amazon Web Services, Microsoft Azure, and Google Cloud Platform) all offer means to create and provision resources with IaC. For example, AWS offers a complete service called AWS CloudFormation that that is devoted to this purpose.
Using CloudFormation, developers define their infrastructure in json or yaml. These documents can be as simple or as complicated as you want; allowing you to define just a few resources, or relying on CloudFormation to deploy your entire application’s architecture. For example, a CloudFormation template that creates a Lambda function looks something like this:
After defining your template, developers either upload their templates directly through the console or programmatically. The IaC provider takes it from there and its their responsibility to provision the resources defined in your template.
One of the obvious first questions is – what if something fails? I mean, you could potentially define templates that provision hundreds if not thousands of resources. What happens if one of them fails? The neat part about most of these services is that can be configured to automatically roll the changes that were already made as part of the upload. This mechanism provides a fault tolerant and safe way to update infrastructure.
Why use Infrastructure as Code?
Have you ever fat fingered something in the console? Maybe it was a simple misclick, maybe it was something you thought was the right thing to do but ended up bringing down your entire system. Regardless, changing things individually and through the console is a recipe for disaster.
The list below is not exhaustive, but highlights some of the main advantages I have personally found using Infrastructure as Code for the past 5 years.
Change Confidence with Code Reviews
As a quick little side node, S3 (one of AWS’ oldest and most widely used services) was brought down when an engineer executed a routine command with a malformed input. Read all about it here. Although note directly related, if this change was reviewed through a code review process, its likely this would have never happened.
Back onto IaC, one of the main benefits is that instead of risking developers fat fingering a button in the console, you can instead take advantage of code reviews of infrastructure changes. Incorporating this process into your development process is key to ensure changes are validated amongst peers before being deployed. This also allows developers the opportunity to collaborate with their peers during the review process instead of after the fact
Easy Regional Expansion
IaC also provides other benefits in terms of regional expansion. Often in software, we create separate application ‘stacks’ in different geographic regions. This is to ensure where our product is hosted on the cloud is in close proximity to our end user in order to optimize latency.
The process described above is called regional expansion and it is the bane of any software developer or DevOps engineer (that is, assuming you aren’t using IaC). Think about how you would replicate a stack hosted in North America over to europe. You would have to go to your cloud providers console and meticulously take note of every resource, every interconnection, every setting, and create a 1:1 copy of they infrastructure in the new region. With big applications across different teams, the amount of effort to pull this off is herculean.
This problem is virtually eliminated with IaC. With IaC, we write code that reflects our infrastructure layout. When the time comes to create a new stack in a different region, we simply provide that region as the input for our template. The IaC provider takes care of deploying those resources.
This effort is minimal and allows developers to spend more time on problems that actually matter.
Summary
In this blog post, we talked about what Infrastructure as code is, why its useful, and why you should start using it. If you’re interested in learning more about Infrastructure as Code, check out AWS Cloudformation or Terraform, two popular solutions used to write code to create infrastructure.