Why Should I Use Version Control for My Infrastructure?

Transcript

I used to be a sysadmin, and back when I was building machines, we would buy a server and stick it inside of a rack, connect the cables to it, and then load the OS and configure that machine. And we would often keep these machines up and running for months or years at a time. And each machine got its own name.

Things were simpler back then. A sysadmin might have to manage 50 or 100 machines at a time. Fast forward to today and the sysadmin is expected to manage thousands of machines, and you'll be building them and tearing them down every day.

Managing thousands of machines can be very challenging. You need to have good automation in order to do this.

Hand-built machines vs. infrastructure as code

This brings us to the idea of infrastructure as code. Instead of building machines by hand based on a set of instructions, we are now using code to express what we want to build.

Infrastructure as code is the idea of defining everything you need to build in a programming language like Terraform (HCL) and then using that code to stand up your infrastructure, reducing or eliminating any manual steps that might cause errors or differences in the machines you're building.

The evolution of version control

That brings us to version control. What is version control? The first version control systems came out in the 1980s, and these were tools that programmers would use to keep track of changes to their programming code.

Tools like RCS came out in the early '80s, and today we have version control systems like Git, which allow multiple users, maybe in different locations, all to collaborate on the same codebase. When you define your infrastructure as code, you can use these same tools to store your infrastructure code. And it gains you a lot of advantages that the application developers have been using for many years.

3 advantages of infrastructure as code

The first advantage is that you have an audit trail of every single change that goes into your environment. Instead of building a server by hand and then hoping that it comes out correct, we have all of the instructions stored in this repository or on this server so that when I build that machine, it comes out exactly the right way every single time.

Infrastructure as code ensures that you have consistency, that you have a clear track record of anything that went into your codebase. Then, if a machine ever went down, you could easily rebuild it in a short amount of time without too much trouble.

So the first advantage is consistency and a clear audit trail that shows any changes that went into your environment. That way, you don't have unexpected surprises or machines that maybe you're not quite sure how they got built.

Second advantage of using infrastructure as code is that you can test that code. You can build automated test pipelines that will stand up your infrastructure and run tests against it without any human intervention at all, so that if you make a change to the codebase that builds your infrastructure, the test pipeline can catch errors before they go to production. And no one likes to find out about an error in their code because it got pushed to production by accident.

Third advantage to using infrastructure as code and version control systems is that you can easily promote changes from dev to staging to production in a simple and seamless way. Sometimes dev and staging and production might not look quite the same. And so errors can slip through. You could push a release to QA and it works, and then when you go to deploy it to production, something goes wrong and it fails.

This can be very expensive and time-consuming. Many organizations will have what they call a "maintenance window." Let's say it's on Friday night, from 8 p.m. until whenever we're finished. And 25 people have to be on this call getting ready to deploy the application. This is a very expensive and time-consuming operation.

Syncing up dev, staging, and production

Imagine how it feels when at 2 a.m. you realize something broke, we have to roll everything we changed back, and then get everybody together the next week to do the same thing again. If you'd like to know the words not to say to a sysadmin at 2 a.m. during a maintenance window, the worst thing you can say to that sysadmin is, "It worked on my machine." No sysadmin wants to hear that it worked on my machine, because I can't put your laptop into the datacenter.

So we need to make sure that dev, staging, and production all look exactly the same. By using infrastructure as code and version control systems, you can ensure that dev and staging and production do look the same and that when you deploy to dev and your QA environment and it works, you can be very confident that deploying to production is also going to work.

So there are 3 advantages to using version control systems and infrastructure as code. One is speed. You can go a lot faster when you deploy using infrastructure as code in your version control system.

The second reason is reduced risk, because you know of every single change that went into your environment, you don't have to worry about unexpected changes that could break things or possibly expose you to hackers or other risks.

And then finally, we make you more efficient. Fewer failed deployments means that you can deliver new features to your users more quickly and efficiently and not have to keep your operations team up until 2:00 in the morning troubleshooting bugs that should have been caught during the testing phase.

There are many advantages to using version control systems with infrastructure as code, and you can gain all these advantages using HashiCorp Terraform.