---
A few months ago, I was interviewed by PeerSpot about my experience with HashiCorp Terraform. It made me think back to where we started — and how far the team has come. This is the story of how two tools changed the way we provision infrastructure.
Before this project, I came from an environment managing almost 3,000 physical servers. We weren't doing everything by hand — we had a workflow: the security team provided a baseline, we used Ansible to apply configuration including IP setup, security hardening, and disk partitioning. Once the image was ready, we uploaded it to Clonezilla. When a new server was needed, we restored the image from Clonezilla and ran a script to configure the IP.
It worked. But it had a ceiling. The Clonezilla approach is image-centric — you restore a snapshot and patch things on top. It's not declarative, it's not version-controlled in a meaningful way, and as the environment grows, keeping those images consistent becomes its own problem. When I joined my current project about a year ago, I wanted to build something more repeatable from the ground up.
---
1. We were doing everything manually — and it was painful
On my new project, the starting point was familiar but different — download an ISO, build a base image by hand, create a VM template in vCenter manually. Every new VM meant importing the template, assigning the VLAN, and configuring the IP by hand.
I'd been through a version of this before at much larger scale. Even with Ansible and Clonezilla in the picture, the fundamental problem remained: the image is a snapshot in time, not a declaration of what the system should be. Every restore is a starting point, not a guarantee. Drift creeps in, and at 3,000 servers you stop trusting that any two machines are truly identical.
Starting fresh on a new project, I wanted to close that gap. The question wasn't whether to automate — it was how to do it in a way that's actually maintainable.
If you're still doing this today, I understand — it feels like "this is just how it works." But there's a better way.
---
2. Packer comes first — and it matters more than people think
Most people talk about Terraform. Not enough people talk about Packer.
Packer is what you use to build the base image and VM template automatically. Instead of manually downloading an ISO and configuring a template by hand, Packer automates the entire image build process. The output is a clean, versioned VM template sitting in vCenter, ready for Terraform to use.
The key insight: Terraform is only as good as the image it provisions from. If your base image is inconsistent or manually built, you'll carry that inconsistency into every VM you provision. Packer removes that variable entirely.
Get Packer working first. Understand what it's building. Then move on to Terraform.
---
3. Terraform handles the rest — and it's 10x faster
Once the template exists in vCenter, Terraform takes over. It provisions the VM from that template, assigns the VLAN, configures the network — everything that used to be done by hand.
The speed difference is dramatic. What used to take a significant chunk of a workday now takes minutes. I'd estimate it's at least 10 times faster than our previous manual process. Right now we're provisioning approximately 30 to 40 VMs for non-production environments, with production coming soon.
But speed is only part of the story. The bigger gain is idempotency. We try to manage our infrastructure the same way we manage configuration with Ansible — apply it, and the result should always be the same clean state. No surprises, no drift between environments.
---
4. State management is where most people get into trouble
Terraform state is what tracks the real-world infrastructure Terraform manages. If you don't understand it — or worse, if you manage it carelessly — you will eventually have a bad day.
We store our Terraform state in S3, not locally. Local state is fine for learning, but in a team environment it becomes a liability fast. Two people running
terraform apply against local state files will conflict. S3 with state locking removes that risk.My advice to anyone starting out: before you provision a single resource in production, understand how Terraform state works. Read the documentation. Understand what happens when state drifts from reality. This is the one area where investing time upfront saves significant pain later.
---
5. Structure your code before it becomes a problem
One thing I'm still improving is how we organize our Terraform code. Early on, everything was in a flat structure. As the number of resources grew, that became harder to manage.
The approach I'm moving toward: separate directories per workload type — one for database VMs, one for Kubernetes cluster VMs, one for any other VM category — with a root module that brings them all together. This makes it much easier to manage non-prod and production environments independently without mixing state or configuration.
Modules are key here. We separated one central module so we can reuse the same logic across environments while keeping the environments themselves clean and distinct. Think of it like a library — write it once, use it consistently everywhere.
---
6. One unexpected benefit: it taught me things I didn't know
When you're doing everything manually, you develop workarounds. You get used to clicking through vCenter and moving on. Terraform forced me to understand the infrastructure more deeply.
One example: working with vCenter datastore clusters. Before Terraform, I didn't have to think about how datastore clusters worked in detail — I just picked a datastore. When I had to express that configuration in Terraform, I had to actually understand it. The tooling made me a better engineer, not just a faster one.
That's a side benefit worth mentioning to anyone who worries that automation means less understanding. In my experience, the opposite is true.
---
Final thought
If your team is still provisioning VMs manually, Packer and Terraform are the first two tools I'd recommend. The initial investment — understanding the tools, structuring the code, getting state management right — pays back quickly and keeps paying.
I've seen what managing nearly 3,000 servers by hand looks like. I've also seen what one year of proper automation can do on a new project. The difference isn't marginal — it's a completely different way of working. Smaller team, less toil, faster delivery, fewer incidents.
I gave Terraform an 8 out of 10 in my PeerSpot review. The missing two points are on me, not the tool. I still have more to learn. But one year in, I'd make the same decision again without hesitation.
---
Read my full PeerSpot review: Automation has transformed VM provisioning and now delivers fast, consistent environments
Want to talk infrastructure automation? Get in touch.