When should you be using infrastructure-as-code?

A question I hear quite frequently when consulting companies of various sizes is if they should employ infrastructure-as-code to manage their cloud resources. In this article I will try to shed some light on what exactly infrastructure-as-code is, when and why you might want to use it, how to choose the right tool, and how to integrate it into your current workflows.

What is infrastructure-as-code?

Infrastructure-as-code is, as the name implies, a technique to describe cloud resources in code or a code-like manner. Traditionally, cloud infrastructure was often described in lengthy textual architecture documents and then manually deployed – either through CLI commands or by clicking buttons in the UI of the cloud provider. Infrastructure-as-code on the other hand allows describing the infrastructure in a domain-specific language that then can be executed directly against the cloud to deploy or change the infrastructure.

Why should I use infrastructure-as-code?

Eliminating the disconnect between the description of your infrastructure and the actually deployed infrastructure is not the only benefit of infrastructure-as-code. Switching away from manually having to click buttons also allows you to have a review process that's similar to the one you most likely already employ for changes to your applications code. Instead of reviewing a bunch of manual steps in an execution plan, engineers can review actual code changes and an automatically generated change-set generated from it. Aligning these two review processes simplifies your deployment setup, reduces complexity, and, in many cases, makes achieving certifications such as SOC 2 much easier.

What's more, having your cloud infrastructure description in a version control system allows you to easily track changes over time. This is especially useful when trying to correlate changes in metrics or bugs to specific changes of your infrastructure. If necessary, rolling back to an earlier state is of course also greatly simplified and follows, again, the same process as your regular software development process.

Another benefit is that having your infrastructure described as code allows reusing certain parts of your infrastructure. On one hand this greatly reduces spin-up time of new (micro) service in a service-oriented-architecture. That benefit however often only benefits larger organizations as many smaller startups only operate one service at the beginning. However, the code reuse also applies to different environments: The staging and the production environment can use the exact same code modules which guarantees that the two stacks are as identical as possible – which in turn makes it really easy to test infrastructure changes in staging first before releasing them to production.

And lastly, infrastructure-as-code allows you to quickly spin up your infrastructure again in the case of a disaster such as when an entire AWS region disappears off the face of the earth.

When should an organization start using infrastructure as code?

As outlined above, the benefits of infrastructure-as-code are monumental. I personally recommend using infrastructure-as-code from day 1 for projects of any size. Infrastructure-as-code can prevent costly outages, simplifies the development process, and makes adding new environments dead simple! What's more, switching to infrastructure-as-code at a later point is often more complicated than just using it from the get go.

Which infrastructure-as-code solution should I use?

There are multiple infrastructure-as-code solutions out there which often leads to decision paralysis. The most important thing to consider is which cloud provider(s) you are using or are planning to use. Some infrastructure-as-code solutions like AWS CloudFormation only support, as you might have guessed, AWS while others such as Terraform support multiple different cloud providers – you can even mix them in the same repository.

Another thing to keep in mind is which programming languages you are utilizing today and thus are familiar with. While AWS CDK allows you to choose between a wide range of programming languages such as Python, TypeScript, JavaScript, Java, and Go to describe your infrastructure, other tools use a specialized language that you most likely won't be familiar with.

However, any tool is better than no tool at all so don't let decision paralysis get in the way of adopting the paradigm!

How do I start using infrastructure-as-code?

As pointed out previously: The earlier you start using infrastructure-as-code, the better. It's best to adopt a policy that doesn't allow creating any cloud resources manually.

When introducing infrastructure-as-code to an organization that is already using manually created cloud resources, it's often preferable to spin up a new stack in parallel rather than trying to import the existing infrastructure into the new framework. This way you can rest assured that your descriptive code covers your entire infrastructure and that you can spin it up from scratch in case of a disaster. It also reduces the risk by allowing you to leave the existing infrastructure untouched so you can test the new infrastructure until you are ready to make the cut.

Regardless if you are exploring infrastructure-as-code for a brand new startup or for an established organization, I am here to help! I have worked with numerous companies of various size to spin up reliable and scalable infrastructure in the cloud. Contact me today to learn more.