Infrastructure as Code

Infrastructure as Code is one of the important facets of configuration-management systems. Generally, an environment is provisioned using manual efforts, such as using a self-service portal or wizard that provides step-by-step directions to configure a resource. It might go a step further and the environment can be provisioned using scripts, such as PowerShell and Bash. These scripts can then execute either manually or automatically using an orchestrator tool.

There are some serious limitations in using any of the previously mentioned approaches:

• Lack of repeatability, consistency, and predictability during provisioning and updating environments. The configuration values for scripts are either entered manually by copying from documents and Excel sheets.
• Lack of diagnostic information and it's difficult to figure out the exact error location.
• Human error while providing configuration values.
• Lack of confidence in deployments.
• Lack of efficiency and speed.

These limitations demand using a more systematic and automated approach for the creation of environments and the deployment of applications.

Infrastructure as Code can help remove these limitations. At a high level, Infrastructure as Code refers to the process of defining environments using code and then using it to create environments. However, Infrastructure as Code is much more than this. Infrastructure as Code mandates that infrastructure definitions after it's converted into code should follow the same application life cycle management principles that typically is followed for applications, they are as follows:

• They should be versioned and stored in a version-controlled repository. Developers should be able to author infrastructure-related code and push them into the repository.
• The repository helps with collaborating among developers about code related to infrastructure.

• There should be a process established to verify and validate the changes done to infrastructure code to ensure that only well-tested code is deployed to higher-level environments.
• After verification, the code should be stored in a place that can be used by all the environments for creation and updates.
• Configuration information for each environment should be stored alongside the actual infrastructure code. These configurations can then be applied to each environment as applicable.
• After the infrastructure code is deployed to pre-production and production environments, appropriate operational validation should be conducted to ensure that the environment is behaving as intended and meeting expectations.
• There should be active monitoring of the environment and any deviation from the known desired configuration should be reported back.

The following screenshot is depicting the process followed for Infrastructure as Code: