Infrastructure as Code (IaC)

Instead of clicking through a cloud console or running ad hoc commands on a server, teams describe the desired infrastructure in code files. A provisioning engine reads those files and reconciles the real environment to match the declared state. Because the definition lives in a Git repository, every change is reviewed, versioned, and reversible.

Two main approaches exist:

• Declarative: you describe the end state ("two web servers, one database, one load balancer") and the tool figures out the steps to reach it. Terraform and CloudFormation work this way.
• Imperative: you specify the sequence of commands to execute to reach the state. Traditional scripts and parts of Ansible follow this model.

A related concept is idempotency: applying the same configuration multiple times produces the same result, so re-running a deployment never creates duplicate resources or drift.

For a B2B software project, IaC turns infrastructure into an asset that is documented, testable, and shared by the whole team rather than locked in one administrator's memory. The main benefits are:

• Reproducibility: spin up identical staging and production environments from the same code.
• Version control and auditability: every infrastructure change has an author, a diff, and a history.
• Faster recovery: rebuild a compromised or failed environment from the repository instead of from manual notes.
• Reduced configuration drift: the code remains the single source of truth.

The tooling landscape splits broadly into provisioning (creating resources) and configuration management (setting up what runs on them):

Terraform and Ansible are frequently combined: Terraform creates the infrastructure, then Ansible configures the software running on it.