Salesforce, Python, SQL, & other ways to put your data where you need it

Need event music? 🎸

Live and recorded jazz, pop, and meditative music for your virtual conference / Zoom wedding / yoga class / private party with quality sound and a smooth technical experience

Choosing Terraform vs. Ansible

12 Nov 2025 🔖 devops
💬 EN

Table of Contents

In my Infrastructure as Code (IaC) tool types article, I listed Terraform as a “resource provisioning (day 0)” tool example, and Ansible as a “configuration management (day 1)” tool example.

I don’t hate it … but it hasn’t stopped people from asking me to clarify the difference when…

Honestly, yeah, there’s a lot of overlap.


What Gartner says

Do day 0 and 1 even exist?

Gartner’s all over the place with vocabulary and dividing lines, not only between its articles but even within each, which is super frustrating. (I think I used most of the colors in my 30-pack of highlighters when trying to follow along with the nuances.)

Nevertheless, my brain keeps latching onto believing that Gartner exhibits a tendency to divide the “labor of feeding and caring for” any single given “target” “infrastructure resource” into:

  1. “provisioning” – “create/destroy the resource
    • (if the resource is of the type that has an OS, the rule of thumb is – the kinds of stuff that happens to the resource outside of the OS’s awareness)
  2. “configuration management” – “edit the resource to make it actually-useful
    • (if the resource is of the type that has an OS, the rule of thumb is – the kind of stuff that you can’t accomplish unless the OS is running)

Which tool for which day?

Gartner’s “Reference Architecture Brief: Infrastructure Automation and Orchestration” lists Ansible twice:

  1. Once alongside provisioning (day 0) tools like Terraform and Pulumi.
  2. Again alongside config (day 1) tools like Chef and Puppet.

Gartner’s “How to Automate Server Provisioning and Configuration Management” also points out that Terraform is a bit of a provisioning one-trick pony, whereas Ansible has more range.

Soooo … Terraform only for certain things, but Ansible for anything, it’d seem like they’re saying.

And yet … that feels like a bit of an “ick” to me and I can’t quite put my finger on why? Let’s explore that.


Is specialization excellence? Or do I just like Windows?

I guess that begs the question – does Terraform’s tighter scope make it any better of a developer experience, when it comes to trying to author or execute IaC automations?

I don’t actually know.

I’m pretty sure that I stand by advising people “if you’re provisioning, default to Terraform if you can.”

Honestly, though, I think my advice boils down to Ansible’s command-line interface not being able to run on Windows, which means it can’t run on the average enterprise employee’s laptop. I’m a proof-of-concept noodler, so I presume everyone else is. 🤷‍♀️


Think about the operating system

Here’s my mental flowchart:

Do you SSH or WinRM into a running OS to do the work?

To get the work in question done, do you need to connect remotely over SSH or WinRM into a running Linux/Windows operating system’s command-line interface? (Or remote-desktop into a running operating system’s graphical user interface so that you can click buttons with a mouse?)

If yes, you almost certainly need “configuration management” framework like Ansible.

  • All such frameworks are, arguably, just glorified “shell scripting, but they hide the act of writing shell scripts from you under the hood, and add some built-in logging and testing and declarative syntax and idempotence for you, so you don’t have to take care of that when you write your part of the code.”
    • (Which is an incredibly useful thing for a framework to offer you; don’t knock it! It’s why we use IaC frameworks, not just shell scripts!)
  • e.g. Ansible if you’d prefer to force code to run on the running target OS by SSH/WinRM’ing into it and running code through the target OS’s remote CLI sesson.
  • e.g. Puppet, Chef, Microsoft Configuration Manager, etc. if you’d prefer the running target OS to poll for its own work-to-be-done and take care of queueing it up for execution.

Here are two key questions to ask yourself:

  1. To patch from “the way we like things configured, version 3” to “the way we like things configured, version 4,” do I need to SSH/WinRM into anything?
  2. If the answer to question #1 was “yes,” am I sure I need to SSH/WinRM into anything? Am I 100% sure I have to treat this target resource as a “pet” / “fine china?”
    • Could I treat the “the way we like things configured, version 3” resource like “cattle” / a “paper plate” and simply … destroy it?
    • And swap in a new resource that’s already on “the way we like things configured, version 4”?
      • (If so, then nevermind, it turns out you have a provisioning problem, not a configuration management problem. Congratulations, you’ve done a DevOp by converting a “Day 1” problem into a “Day 0” problem, and now you get to go onto the next section!)

Do you get the work done over HTTP?

If not SSH/WinRM, then how do you connect into whatever it is that can get the work done?

  • HTTP(S) is probably the most common answer to that question.
  • For example, all of the major Terraform/Ansible/etc. providers/collections/etc. for working with public cloud providers like Azure, AWS, GCP, etc. are just wrapper code around making HTTP requests to the vendors’ HTTP(S) APIs.

Both Terraform and Ansible are full of such vendor-authored libraries, so…

  • If it matters to you to be able to noodle around with running the code you’re draft-authoring on your own computer, then try learning to write Terraform code and using vendors’ Terraform providers. (Or OpenTofu, or Pulumi, etc. etc. etc. One of the “provisioning one-trick pony” IaC frameworks that is not really meant for SSH/WinRMing into running operating systems.)
  • If, like, 90% of your “work to be done” is “configuration management” that calls for Ansible, then yeah, you might want not want to learn a second IaC language. Maybe it makes sense for your team to suffer the “isn’t easy to test from a Windows laptop” frustrations but enjoy the “only have to learn one programming language” benefits, and also use Ansible for your “provisioning” work.

Other

Probably the same idea. If “making things happen” doesn’t involve you making something happen inside a target infrastructure resource’s running OS, there’s a good chance that the vendor has already authored a Terraform provider to make that thing happen. Take a look. 🤷‍♀️

--- ---