I’ve 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 I’ve 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, I’d 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 I’m 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 I’ve 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 application’s 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
Top comments (1)
Great article!
Would be interesting to take a look on how the pipelines are set up, especially in regards to different environments.
Do you have pipeline triggers on folder level, so for example when you update something in "DBTek Dev" folder, you run a pipe only for this, and do not run pipes for the other environments?
Thanks!