There’s a whole chunk of the software development world that takes Infrastructure as Code (IaC) for granted. They’ve been at it for years, are totally bought in, and don’t really need to consider the benefits any more because it’s just the air they breathe. But it turns out there are still a lot of environments that are being managed manually, carefully, and painfully.
If you went to tell your manager that you need to spend time using Cloudformation or Terraform to implement your new environment because you can version control it or automate it, you probably wouldn’t get very far. Unless you’re fortunate enough to have a manager who is intimately familiar with software development, in which case, you probably don’t need to sell it.
Versioning and automation are the features of Infrastructure as Code, not the reasons why you would want it. My goal is to get to the why behind Infrastructure as Code, and what you can expect to get out of it. And at the end, we will talk about a few of the tradeoffs you might experience.
Confidence
Yes, you read that right—confidence. Have you ever managed an environment created manually? Are you terrified with every change you have to make? Do you push back against even the smallest changes because you fear what might happen? Are you worried about backups being corrupted, and the server crashing, and being unable to recreate the environment? Are those scenarios the basis of every anxiety dream you’ve ever had? I got a little twitchy just typing them out.
Infrastructure as Code gives you the freedom to make changes without the fear that you’ll put things in an unrecoverable state. And it gives you a better understanding of how the environment came to be the way it is, which allows you to be more confident to make the changes you need.
Is it safe to remove this environment variable? Why was this flag set? How did that configuration file get in that state? Who added that site to the server? With Infrastructure as Code, you can look back in the source history and find out the answer to all those questions. And if that change breaks the environment? Well, just roll it back. Did that still not fix it? Build a whole new environment with a few keystrokes. That is the kind of magic that IaC enables.
Repeatability
Even in a software environment where you have a lot of tests, one of the biggest causes of failure is having integration/staging environments that don’t properly mimic production. Infrastructure as Code eliminates this problem by allowing your infrastructure to be instantiated in an automated way, making it easy to build multiple identical environments.
Doing Infrastructure as Code in the cloud adds another huge advantage—you can build specific environments for each release, rather than having dedicated testing environments. This can be a boon particularly if you need to modify your environment along with your software releases.
Troubleshooting
Have you ever had an environment change cause problems, but you’re not sure what changed? Infrastructure as Code virtually eliminates this problem because you can look at your source control and see exactly what changed in the environment. As long as you are diligent and don’t make manual changes to your environments, then Infrastructure as Code can be a game changer.