Over the recent 2023 holiday one of my clients was experiencing an unexpected spike in latency. They called me in to help fix the problem. It started digging in and found a few sharp changes in the metrics. When I see those I often ask “What changed?”. Some of their developers told me that their internal lead infrastructure person had made some changes around then but that no specifics of what those changes were. Their internal infrastructure guy was on vacation for the whole week and was unavailable for a call so we were flying a bit blind.
I had been trying to push Terraform, currently my favorite Infrastructure As Code solution, on this client for a while but they had not jumped on board yet. Had they embraced infrastructure as code and basic VCS Pull Request approval flow we would have had full knowledge of what went live, roughly when, and, if you are using good commit messages, why the change was made.
You probably have a similar flow with your code. A developer commits code changes, then submits a pull request, someone else approves it, and finally it gets merged in to be deployed. In an ideal world the same would be true for changes made to your underlying infrastructure.
This is one of dozens of problems that Terraforms and other infrastructure as code tools help eliminate. Here are a few of the other benefits:
You can plan out changes before you execute them so you can examine every little change before it goes live.
Perhaps someone or some process makes some manual changes that do not match what is defined in your IoC code? A tool like Terraform can help you detect those changes, then you can decide whether or not to change it back or update your IoC to include the changes.
When rolling out changes to each of your environments(development, QA, production, etc) those changes can be perfectly replicated from one to another so you can have consistency across the board. Additionally you can use variables to change things like compute capacity so you are not paying for a ton of unused compute capacity on an internal facing environment like your “dev” environment.
One of my favorite things that you can do with a tool like Terraform is to define reusable modules for common usage patterns. For examples check out all the free open source modules at schematical.com/free.
Another great feature that I would never use Terraform without is saving state to the cloud, in my case specifically S3. The last thing you would want is 2 different engineers making changes to your infrastructure each with their own locally saved state. If that was the case they both would have different locally saved versions of what Terraform thinks is the state. Basically it would be like a house of mirrors. Save your state to the cloud, it is easy and built right into Terraform.
You might be saying “This all sounds amazing but what are the drawbacks?”. Truth be told sometimes you get some weird errors, like really weird and man is it cryptic a lot of times. If your state gets out of sync or you try to change the path to a module ohhh boy that can get weird. But I have not come across an error. I couldn't work around with a bit of creative thinking.
Additionally backward compatibility is something else to be aware of. Its getting better now that Terraform is more established but I have seen some discrepancies when upgrading from one version of Terrain to another.
Infrastructure as Code is an amazing innovation in the field of virtualized cloud computing. I strongly suggest you consider using it to help manage your cloud based infrastructure.
If you are looking for some help getting started with IoC I released a handful of open source Terraform modules I find useful for everyday tasks here along with some helpful Youtube videos to guid you through using them.
And if you need a bit more help check out my Group Coaching Program on schematical.com
Signup for the mailing list