I define infrastructure as code on every project I run, and Terraform is one of the two ways I do it — the other being CloudFormation and AWS SAM when a system is entirely on AWS.
Why it’s worth doing properly
Infrastructure configured by hand in a web console works right up until the day you need to change it, recover it, or explain to someone what it does. Then it stops working very sharply, usually at the worst possible moment.
Terraform fixes that, but only if it’s the whole picture. Half-managed
infrastructure — some in code, some clicked into the console by whoever was on
call — is arguably worse than neither, because now terraform plan lies to you.
The valuable work is usually getting to the point where the code is the truth.
I’m also pragmatic about the choice of tool. If your systems are all on AWS, CloudFormation or SAM may serve you better than adding another moving part. Terraform earns its place when you span more than one provider, or when your team already knows it.
What that gets you
- Environments you can rebuild, so a mistake or an outage isn’t an archaeological exercise.
- Changes that go through review before they reach production, rather than being made live by whoever is on call.
- Infrastructure that isn’t dependent on me. Whatever I build for you can be handed to your own team or another contractor from the code.
Terraform work I’ve delivered
- Omnipresent — Terraform for AWS infrastructure alongside Lambda, ECS and SAM.
- ElseWhen — Terraform for GCP infrastructure running Python services on Cloud Run and Cloud Functions.
- Bulb — Terraform alongside Kubernetes on GCP.
Hire a freelance Terraform developer
Contact me about your infrastructure — bringing existing systems under Terraform, or building new ones as code from the start.