According to Wikipedia, Infrastructure as Code (IaC) is the process of managing and provisioning computer data centers through machine-readable definition files. This means that you can treat your infrastructure in the same way as you would treat your application code. So you’ll check-in to version control, write unit tests for it, and ensure it stays consistent with what you have in for multiple environments.
Infrastructure as a code also makes it possible to avoid problems such as unexpected code changes and configuration differences between environments such as development and production.
Another thing to take into account is that you don’t need to use different programming languages, like C# or Python. There are tool-specific languages like Terraform, but these are straightforward and have a lot of documentation around them with features such as being cloud-agnostic. The most important thing you change with infrastructure as code is how you manage your systems and applications. Although IaC helps many aspects of getting and keeping a reliable version of your application on production, it does add value when you add automation to it.
So, what problems does IaC solve?
1. Faster speed and reusability
Once you have your code ready, it is just a matter of clicks to spin up any part of infrastructure whether it is Compute Engine, Cloud SQL, or any network firewall rule that we want to apply to these instances. A code-based approach facilitates the delivery of more activities in less time.
Manually managing the infrastructure will often lead to gaps, no matter how hard we try. IaC solves this problem by having the code as a single source of truth (SSOT). This way, we can ensure that the same configurations are deployed consistently with no discrepancies. For example using the same template across multiple environments — Dev, Test, Staging, and Prod.
2. Security
With IDE security plugins such as security code scan or template scanners such as tfsec, could bring security to the left in a CI/CD pipeline. Hence they reduce frictions and increase adoption for better security validation against security and compliance issues.
Since these are in a CI/CD pipeline so they can provide real-time checks when a code is pushed.
3. Accountability
As all the changes are tracked under version control so we can see the complete history of the changes. If any error occurs it can be traced and post-mortem analysis can be done to avoid such errors in the future.
4. Less documentation and low risks
Most of us like reading documents but they often become outdated at a later stage and not everyone invests enough time into their reading. In addition, a document cannot be tested as a code. But with IaC, the code itself is the updated documentation for the infrastructure. No other documents are needed except for configuration instructions.
As the code is controlled by version, IaC allows you to document, record, and track any changes to your server configuration. Therefore, if there is a problem with the new configuration, it can be identified and corrected much more easily, minimizing the risk of problems or failure.
5. Rule of Modularity
We all must have heard about microservices architecture, the same principles can be applied to IaC. The whole infrastructure can be divided into small modules, for example, Networking, Instance groups, Cloud Builds, etc, this then can also enhance the accountability as to who has access to what.
This approach also reduces the amount of duplicate code and enables us to build a DRY infrastructure
Want to see a Google Cloud Terraform template, it can be found on GitHub here
