Infrastructure as Code (IaC)
How Infrastructure as Code Works
Infrastructure as code (IaC) is the practice of describing servers, networks, storage and other cloud resources in text files instead of creating them by hand through a web console. A tool reads these files and builds or updates the real resources to match them.
Because the description is code, it can be stored in version control such as Git, reviewed by colleagues, tested and reused. The same files can build development, staging and production environments that are nearly identical. Terraform is a widely used IaC tool, and it is one of several options.
Consider a team that sets up a test environment by clicking through a console. Months later, nobody remembers which settings were changed, and the test setup no longer matches production. With IaC, the files themselves would show exactly what exists and how it was configured.
Declarative vs Imperative Infrastructure Code
IaC tools generally follow one of two styles. The difference is whether you describe the result you want or the steps needed to reach it.
- Declarative: you describe the desired end state, such as three web servers and one database. The tool works out which changes are needed to get from the current state to that end state.
- Imperative: you write the exact sequence of actions, such as create a server, attach a disk, then install software. The result depends on each step and on the starting point.
Declarative tools are popular because the same description can be applied again and again. If the environment already matches it, the tool makes no changes. Imperative scripts may fail or duplicate resources when run a second time, because the first run has already created some of them.
Drift, Repeatability and Trade-Offs
Drift happens when a live environment no longer matches its code. It usually starts with a manual change made in a console during an emergency and never recorded. Drift makes problems harder to diagnose and can cause the next automated update to overwrite a needed fix.
Repeatability is the main reason teams adopt IaC. Rebuilding an environment after a failure, or launching a second copy of a system in another region, becomes a matter of running the same definitions again. Changes can also go through the same review process as application code, which leaves a history of who changed what and why.
IaC has costs. Teams need to learn the tools, the state information must be protected, and a mistake in a shared definition can spread to many resources at once. Its value grows with the complexity of the setup. For related ideas, see what cloud-native design means.
Frequently asked questions
Is infrastructure as code only for large companies?
No. Small teams and solo developers use IaC too, especially when they rebuild environments often or want a record of how their setup changed. The cost is the time needed to write and maintain the files, so the benefit is clearest when infrastructure is complex or changes frequently.
Does infrastructure as code lock you into one cloud provider?
Not by itself. IaC tools such as Terraform can manage resources from several providers, but resource definitions are usually tied to each provider's services, and team skills and modules can become dependent on one ecosystem. Keeping provider-specific details in well-defined modules reduces that dependence. See what vendor lock-in means.