Benefits of Deployment Using IaC Model

In the pre-cloud era, the operations team provisioned the required infrastructure based on demand. Typically, this setup process involves multiple approvals, and it usually takes a few weeks before the hardware is successfully provisioned.

Challenges with manual infrastructure provisioning

Manually provisioning the infrastructure caused a lot of challenges to organizations:

• The servers needed to be patched and updated on time.

• The deployments were slow because manual provisioning had to happen before the software could be installed.

• Infrastructure costs were high as there was no option to scale down during the off-peak season.

• Outages during the peak season as the infrastructure needs to scale up quickly to meet the sudden spike in traffic.

• Auditing infrastructure changes were complex.

• Errors occurred during the provisioning, patching, and updating processes.

Infrastructure as code (IaC) to the rescue

In the cloud era, the infrastructure provisioning time has significantly reduced from weeks to minutes. Today, all public cloud vendors provide the services to dynamically provision the infrastructure by writing code. While previously, software developers used to write code only to build applications and not infrastructure, the infrastructure as code (IaC) approach enables managing and maintaining infrastructure by writing software code instead of relying on manual processes. So, just like the application source code, the scripts that provision the infrastructure can be committed to a version control system and tracked for changes. Like testing software code, the QA team must test the scripts that deploy the infrastructure before using it in production deployments.

Approaches to infrastructure as code (IaC)

There are two distinct strategies to approach IaC:

• Declarative approach: In this approach, the operations team defines the target state, including the resource and their properties, and the IaC tool will provision the infrastructure to meet this need. This approach is essential if the teams need infrastructure idempotency, which means the provisioned infrastructure will always be the same irrespective of the number of times the scripts are run.

• Imperative approach: This approach is very close to how a human thinks, and the scripts define the steps to achieve the desired solutions and the sequence in which they must be executed. The user has direct control over the automation, with no focus on the target state.

Though both approaches use two different strategies, they both follow three common execution steps:

1. The scripts must be developed by a developer or by operations personnel and eventually parsed using tools like TerraForm or AWS CloudFormation.

2. These files are committed and maintained in a centralized source repository.

3. The final step is to create and configure the infrastructure as defined in the implementation scripts.