I Store My Infra-as-Code This Way, You SHOULD Too.

Ive recently sent a poll on my YouTube channel community tab, asking where people store their IaC, Infrastructure as Code.

With my surprise, more than half of the people said that they always store their IaC scripts and their application code in separate repos.

In this article I will discuss those results, and tell you how and where I store my Infra as Code files, and why I think you should do the same as well.

Video

As usual, if you are a visual learner, or simply prefer to watch and listen instead of reading, here you have the video with the whole explanation and demo, which to be fair is much more complete than this post.

Link to the video: https://youtu.be/Ub76JGoXzKI

If you rather prefer reading, well... let's just continue :)

About IaC

As Ive mentioned in the intro, today we talk about how to store your IaC, Infrastructure as Code, which is the way to describe, create and manage your resources using some definition language.

If you are not very familiar with it, and want to know more, Id recommend you to check out the video I made about what IaC is and why using it. You can find it here

How I Store My Infra as Code

Alright, enough of that. How do I store my Infra as Code? Well, it depends.

I can say I do it both ways, I would have picked the option in the middle, in my poll above. And the reason for this is very easy to explain: it depends on what the IaC script or model Im writing is for.

I tend in fact to split my IaC into two parts: foundational infrastructure and app-related one.

Foundational Infrastructure

Foundational infrastructure comprises of all the pieces that are not directly related to a specific app or service, but are instead more general and perhaps shared between different applications. Examples of this could be some Virtual Networks used by multiple services, storage accounts for storing logs, or Kubernetes clusters.

Since those are independent from the software parts, I store them in a separate centralized repository. As you can see in the image above, I have different folders for different environments, and in each I have the resources.

As Ive mentioned, you can see I define here the AKS Kubernetes clusters, the networking resources, etc.

And as you have probably noticed, I use Terraform for my IaC. And I like to separate my resources into modules.

I store their code in separate repositories in GitHub, and publish them to the HashiCorp cloud, on my private registry, together with the Terraform state.

Let me know in the comments if you want to know more about how I structure my Terraform IaC modules and files.

App-related Infrastructure

Alright that was about the shared foundational infrastructure. So what about the other piece of IaC I've mentioned? The one related to the applications? Well, as you have probably already figured, I store it together with the application code, in the same repo.

As you can see here, I have my application code but I also have this ARM Template folder in the root of the repo, in which I have the IaC scripts for this particular piece of software.

In this case this was ARM but I do the same for Terraform, which, as I've mentioned, is my IaC provider of choice.

I store this way all the Infra as Code that provisions and manages resource only related to a specific application. That could be an App Service Web App where my web application runs, a Virtual Machine that hosts a server-management tool, or an API Management solution that provides the gateway for my applications APIs... and of course the list can be endless, but you got the point.

Why The Double Approach

Not only do I store my IaC it this way, but I usually recommend this to the teams and companies I work with. Storing your Infrastructure as Code with this "double approach" gives a lot of flexibility. For example, you could have a centralized infra management team taking care of all the shared infrastructure which provides the foundation of your environments, while leaving the apps specific bits to the app developers who know exactly what their software needs.

Conclusions

Let me know in the comments below how you store your Infrastructure as Code and what you think about my approach.

Also, check out this video in which I go through the reasons why you should use Infrastructure as Code.

Like, share and follow me for more content:

YouTube
Buy me a coffee
Patreon
Newsletter
CoderDave.io Website
Merch
Facebook page
GitHub
Twitter
LinkedIn
Podcast