Why Infrastructure As Code Is Lit

But first, what is Infrastructure as Code?

Infrastructure as code (IaC) is closely linked to DevOps and is considered as one of the best practices that can help an organization achieve a mature DevOps culture. This is because IaC helps engineers to follow Clean Coding and DevOps principles such as avoiding duplication and using automation.

According to Thoughtworks, IaC, or programmable infrastructure, means writing code to manage configurations and automate provisioning of infrastructure in addition to deployments. This is not simply writing scripts, but involves using tested and proven software development practices that are already being used in application development. For example: version control, testing, small deployments, use of design patterns etc. In short, this means you write code to provision and manage your server, in addition to automating processes [0].

With that being said, the following article exemplifies the impact, the benefits and most importantly: The smiles that IaC can bring within any given software organization.

It makes Site Reliability Engineers happier

Let’s say that there is a cloud-based company that manages the client’s Personal Identifiable Information (PII) operating in the U.S. and it is planning to expand to Europe. Although the company complies with all the U.S. regulations, that doesn’t mean that it also complies with Europe’s regulations (e.g. GDPR). For example, data cannot be stored between regions (EU and the U.S.) so the company might be forced to create separated deployment environments for each region. As a result, the information generated by European customers will remain in Europe while the information of U.S. customers will be stored in America.

Here is when IaC can become quite handy since being able to replicate any given deployment environment within minutes can bring a lot of benefits such a big smile in a hard working Site Reliability Engineer (SRE) and keeping consistency across environments.

Similarly, not because a company doesn’t have a big expansion plan means that it cannot benefit from the usage of IaC. For example, an organization could easily replicate an environment for them to be able to invite externals to an internal bug bounty program or to create another environment in order to perform stress testing.

Another way someone can make any SRE smile is by requesting infrastructure via a pull request (PR). Suppose that a developer needs an extra database (DB). Instead of messaging or coming over to the SRE’s desk, she can use IaC and request the specific DB she needs with all the desired specifications such as instance type and CPU. This means that when the time is appropriate, the SRE will only need to approve the PR without making any guesses or asking back the developer about a specific detail. The best part is that code is being used, so if there is an issue with the PR, the SRE can just request changes to the developer before accepting it and eventually doing the merge.

It takes every single well-dressed auditor’s breath away

More people are becoming more aware that data is, in fact, a really valuable asset_._ As a result, there are many regulations that are being imposed on organizations that handle sensitive information such as PII, Protected Health Information (PHI), and Payment Card information (PCI). This means that companies that handle and store this type of data are going to be audited to make sure that they are complying with an appropriate standard.

For example, auditors might request access to the audited company’s data center. They might ask information about what is running in server X and who has access to server Y. These questions make a lot of sense from an auditor’s perspective, but what happens if the company runs their infrastructure in the cloud? Not because they run in that way, it means that the regulations do not apply to them. Hence, using IaC would help a lot in this case, because apart from having everything documented, the company can assure to the auditors the following:

In order to request a change, an engineer must have access to the company’s IaC repository
In order for an engineer to make any change, she must be authenticated to a version control service such as Github (hopefully using two-factor authentication)
The code has a full history of changes
Who requested the change X
When exactly the change X was made
Assurance that the change X went under a code review, potentially meaning that it was approved by at least another person (four-eyes principle)

As a result, this information will keep the auditors (and The Security Team) happy since every single request or change will be easily trackable and auditable.

It brings peace of mind to The Security Team

Just because a company is being compliant and it is keeping the auditors happy, it doesn’t mean it is secure. However, doing it can give you a great baseline to build upon and IaC can be a great accelerator to do it.

For example, let’s say that certain backend engineers within an organization need to have access to the infrastructure because they are in an on-call program. While using IaC you can keep track of the access management of each engineer or groups of engineers.

Furthermore, if someone leaves the on-call program, an administrator can revoke or suspend her access management role without accessing the online console of a cloud provider such as AWS or Azure.

This means that besides making the changes visible to anyone that has access to the IaC repository (where all the configuration lives), it would also (theoretically) undergo through a pull request, a code review made by at least another engineer (four-eyes principle), and through a pipeline with all types of automated tests before reaching the production environment. In other words: Using IaC helps to eliminate manual processes that are not visible and that are bug-prone while hardening the security within an organization.

Wrapping it up

This was only the tip of the iceberg of the benefits that IaC can bring to an organization. Nonetheless, there are many things that must be considered before shifting to IaC such as head-count, resources, and prioritization of tasks. However, in the long run, its implementation can be a great investment that will simplify not only the technology aspects of a company but also will bring standardization and value to the processes and to the people within the organization.