SRE Infrastructure as Code
Clicking through a cloud console to build servers feels quick once. Repeating the process fifty times invites mistakes. Infrastructure as Code, shortened to IaC, describes servers, networks, and databases in text files that a computer can run again and again.
What Is Infrastructure as Code?
IaC treats infrastructure like software. Engineers write files that describe the desired setup. A tool reads the files and builds the matching resources. Think of a recipe versus cooking from memory. A written recipe produces the same dish every time, and anyone can read, improve, and share it.
Why SRE Teams Use IaC
- Repeatability: the same files create identical test and production environments.
- Speed: a full environment appears in minutes.
- Review: teammates inspect changes before they happen.
- History: version control records who changed what and when.
- Recovery: a lost environment rebuilds from the files.
Declarative and Imperative Styles
| Style | You Describe | Example |
|---|---|---|
| Declarative | The final result | "Three web servers behind a load balancer" |
| Imperative | The exact steps | "Create server one, create server two" |
Declarative tools compare the wanted state with the real state and change only the difference. Most modern IaC uses this style.
The IaC Workflow
[Write Code] → [Pull Request Review] → [Plan: Preview Changes]
↓
[Monitor] ← [Apply: Build Resources] ← [Approval]
A Simple Example
The sample below uses a generic, simplified format to show the idea. Real tools use their own syntax.
resource "web_server" {
count = 3
size = "medium"
region = "asia-south"
health_check = "/health"
}
resource "load_balancer" {
targets = web_server
}
Changing count from 3 to 5 and applying the file adds two servers. Nobody opens a console or types a command for each server.
Common Tool Families
- Provisioning tools such as Terraform, OpenTofu, Pulumi, and CloudFormation create cloud resources.
- Configuration tools such as Ansible and Chef set up software inside servers.
- Container manifests describe applications that run on Kubernetes.
State and Drift
State
Provisioning tools keep a state file that records the resources they manage. Store the state in a shared, locked, encrypted location so two engineers never change it at the same moment.
Drift
Drift happens when someone changes a resource by hand and the real setup no longer matches the code. Schedule regular drift checks and alert when differences appear. Make the code the only door for changes.
Best Practices
- Keep all infrastructure files in version control.
- Split large setups into small reusable modules.
- Run automated checks and a preview on every pull request.
- Keep secrets in a secret manager, never in the files.
- Use separate accounts or projects for testing and production.
- Tag every resource with an owner and a purpose.
Example: Fast Environment Copy
A team needs a test copy of production before a large release. With IaC, an engineer runs the same files with a smaller size setting. Twenty minutes later the copy exists with matching networks, permissions, and settings. After testing, a single command removes everything and stops the bill.
Common Mistakes
- Mixing manual console edits with code.
- Putting passwords inside code files.
- Building one giant file that nobody dares to touch.
- Applying changes with no preview step.
Key Takeaways
IaC turns infrastructure into reviewed, versioned, repeatable text. Describe the target state, preview every change, protect state files, and treat the code as the single source of truth.
