adaptive.run TECH BLOG

In this article I want to present you some of the benefits of using Infrastructure as Code (IaC).

IaC enables you to get rid of the inconsistencies of your deployments and environments, while allowing you to increase the productivity and deploy faster. On top of these is also the fact that using IaC diminishes the concern that something can go sideways in the Production environment, thus giving you the freedom to make any changes desired.

Infrastructure as Code saves you from wondering if the configuration has been applied correctly to multiple environments or Virtual Machines.

Let’s start with the basics of IaC

Let me give a hypothesis where it was applied a manual change to your environment and something doesn’t work properly anymore.

At this point, you will have a lot of questions that need to be addressed in order to solve the problem. Some of your questions might be: What change has been done? What if the change made broke something? Have I misconfigured something with the release? Perhaps it is not given the correct permission? Why the problem appeared only in this environment and not in others too?

It is a given that manual changes and configuration take up a lot of time which is not beneficial for the deployment process flow.

Today, I want to answer why you should use Infrastructure as Code and help you overcome all of the questions from above that can mess up with your environment.

Why should you use IaC?

Source control

IaC gives you a single source for finding the truth.

Along the benefits of source control, I can state the following: the code of pull requests is reviewed; the code quality will be increased overtime as a result of increasing knowledge sharing with code reviews; changes can be tested in the pull request before merging even to a lower environment; you can configure the build validation to stop the “wrong code” from being merged; eliminates the concern when making changes; allows you to simply revert the latest commit if you made an inadequate change.

Mutable environments

IaC environments have the benefit of being mutable, so you can easily apply changes.

Let me highlight here some of the advantages of the mutability property of IaC: you can easily change stored variables and parameters between environments; you can choose whether to include or not in an environment a part of code for a specific feature; if the situation requires, you are able to scale the environments and determine additional features.

Stops configuration drift

Being in source control, IaC doesn’t permit configuration drift. I mentioned before that source control is the only source of truth, so if you want to make a configuration change that is not in source control, you should be aware that it will not get deployed.

As so, let me list some of the consequences of this configuration drift stopping: changes that are not in source control cannot be deployed; making manual changes won’t trigger configuration drift; if some environments will have different requests, use feature toggles.

Ensure testing for what has been deployed both before and after deployment

Using IaC allows you to create numerous tests and you will have multiple testing suites available.

I will highlight again some of the possibilities this gives you: as part of your build validation, you are able to test during a pull-request; you can confirm that configuration has been applied correctly by testing when it has been deployed; if you want to make sure that no changes have been applied without IaC, you should test the environment on a daily basis.

Enables you to create multiple environments by using the same code-base

It’s all based on repetition. Before the configuration can be deployed intro production, you have to apply it multiple times. Mimic the setup if you want to get your environments to production.

As benefits: when you use the same-code base for all the environments you will eliminate configuration drift between them; deployment of environments is done faster; you can use the same set tests for all the environments which simplifies the testing process; you are able to deploy directly from the code-base when you want a testing environment, with no need to have it full-time running; you can maintain multiple environments a lot simpler from the same code-base.

Visibility aid

You probably bumped into this issue before when your environments expand over time and you want to know what has been deployment in every environment or subscription. By the use of IaC you can definitely improve visibility.

Pros of this feature: you can audit way simpler, because you are able to check code and pipelines to what has been deployed; you are able to check IaC for what has been deployed and when if an issue appeared in one of the environments, ensuring thus a better visibility to troubleshooting.

Costs

Using IaC to deploy will also reduce or compilate costs.

That being said, these are the benefits: you are able to tag all the resources that are created, helping this way with the cost center matter; you can save cost by following a few simple steps to remove a part of IaC that you don’t need anymore; you can receive the costing benefit rapidly by changing a property within the IaC when you are performing a costing exercise and you discover that some of the resources are being down-sized.

Security

Security is also increased when you have more visibility.

Some of the security beneficial effects are the following: you can find out who has done it and what was changed to a configuration, so the audit part is simpler; you are able to pull-requests, which increases a lot the security part because all IaC is peer-reviewed before merging, meaning that this way unnecessary changes can be stopped before applying them to an environment; you can deploy at scale when you want to apply new security principals; security configurations are being deployed at scale for every environment when you roll out so you don’t have to worry anymore about applying different security configurations for each one of them.

Ability to roll back changes

We all know that sometimes problems can appear when you are deploying a change, either because of a misconfiguration, either because an issue to the environment arose from the change, even though you have tested the change priorly.

Benefits: when the hypothesis mentioned appears in IaC you are definitely in luck, because you are able to roll back very simple; IaC enables you to review the changes made and revert to a previous functioning code-base; you can choose what changes to revert and not revert them all.

Troubleshooting

All of the features mentioned before are helping with the troubleshooting process also, as you are able to roll back changes in such an easy way.

To be more precise: you don’t have to check multiple activity logs and ask around the people who worked on the environment to help you understand what was changed and when because you are able to find out precisely what has been changed by reviewing the source control; you can add tools to assist you with the troubleshooting process; by using IaC in such an easy manner you are able to troubleshoot whenever.

Few insights about Continuous Integration and Continuous Delivery (CI and CD)

Let’s start by defining what are CI and CD.

According to the Wikipedia page:

- Continuous Integration (CI) represents the practice of multiple team members who are merging their code changes into a mainline branch several times during a day, while

- Continuous Delivery (CD) represents the process of having releases in a regulated automated manner each time code is being pushed into the mainline branch.

The benefits of CI and CD speak for themselves, considering that you are able to deploy IaC many times per day, at scale and for various environments.

To list a few of the beneficial sides: adaptability to changes is made faster; quicker way of making small changes for agile development introduction; ability to create single or multiple-stage pipelines to deploy the IaC; ability to build triggers, such as automated deployment to lower environments when wanting to apply a change.

Productivity and efficiency increment

If you use IaC you will definitely reduce the possibility of making mistakes or having inconsistencies in your environments.

To understand better, please take into account the following: reduction of human error possibility; deployment only for what is in source control; give team members time for upskilling and use them further into making even more efficient environments; manual tasks decrease, as many things can be automated in an efficient manner.