Terraform vs. Ansible: A Weighted Decision Framework

recommend(
    "New VMs needing config, but operational simplicity weighted 0.60",
    {"provisions_new_cloud_resources": 0.15, "configures_existing_hosts": 0.15,
     "state_and_drift_tracking": 0.10, "operational_simplicity": 0.60},
    scores,
)

New VMs needing config, but operational simplicity weighted 0.60
  Terraform  7.40
  Ansible    7.15
  Both       5.50
  -> recommend Terraform

Even in the exact scenario where both provisioning and configuration matter, weighting the overhead of running two tools heavily enough overturns “use both” — the framework doesn’t treat combining tools as a free win, because it isn’t one.

recommend(
    "Equal weights on every factor",
    {"provisions_new_cloud_resources": 0.25, "configures_existing_hosts": 0.25,
     "state_and_drift_tracking": 0.25, "operational_simplicity": 0.25},
    scores,
)

Equal weights on every factor
  Both       7.50
  Terraform  7.00
  Ansible    6.25
  -> recommend Both

“Both” wins on raw average because it’s the strongest or tied-strongest option on the two biggest-swing factors (provisioning and configuration) and only pays its penalty on one factor (simplicity) — a fact about this specific scoresheet, not a universal argument for always combining the two tools.

scores_windows_fleet = {**scores, "configures_existing_hosts": {"Terraform": 2, "Ansible": 5, "Both": 6}}
recommend(
    "Long-lived on-prem fleet, but it is Windows Server (WinRM, not SSH)",
    {"provisions_new_cloud_resources": 0.05, "configures_existing_hosts": 0.55,
     "state_and_drift_tracking": 0.15, "operational_simplicity": 0.25},
    scores_windows_fleet,
)

Long-lived on-prem fleet, but it is Windows Server (WinRM, not SSH)
  Both       5.60
  Ansible    5.50
  Terraform  4.80
  -> recommend Both

A small, realistic dent in Ansible’s host-configuration fit for Windows targets (versus its native strength on Linux over SSH) is enough to flip the recommendation from pure Ansible to “Both” — close, at 5.60 versus 5.50, which is itself worth noting: real recommendations aren’t always decisive, and a near-tie score is a signal to weigh in factors this framework doesn’t capture (existing team skill, for instance) rather than trust the number blindly.

scores["multi_cloud_portability"] = {"Terraform": 9, "Ansible": 6, "Both": 8}
recommend(
    "New cloud footprint, portability to a second cloud now weighted 0.20",
    {"provisions_new_cloud_resources": 0.40, "configures_existing_hosts": 0.04,
     "state_and_drift_tracking": 0.20, "operational_simplicity": 0.16,
     "multi_cloud_portability": 0.20},
    scores,
)

Terraform’s provider-abstraction model was always its structural advantage for multi-cloud work; adding this factor explicitly and weighting it just makes that advantage visible in the score instead of leaving it implicit in the provisioning number alone.

Because in the scores dict, Both’s provisions_new_cloud_resources score is set equal to Terraform’s (10), on the reasoning that a combined setup still uses Terraform for the provisioning half — that factor contributes zero to the gap. Breaking the full 0.85-point gap down factor by factor: configures_existing_hosts actually favors Both by 0.40 (it inherits Ansible’s strength there for free), state_and_drift_tracking favors Terraform by 0.25, and operational_simplicity favors Terraform by a full 1.00 — 0 - 0.40 + 0.25 + 1.00 = 0.85, exactly the observed gap. The single biggest driver is operational simplicity, but it isn’t the whole story — Both’s host-configuration strength is quietly clawing back nearly half a point that a simpler “it’s all about overhead” explanation would miss. Decomposing a score gap like this, factor by factor, is a useful sanity check before trusting any weighted-scoring result.