Terraform should have remained stateless
Basically agree with the article. I&#x27;ve used direct cloud formation, AWS SAM, Ansible, terraform, and AWS CDK to spin up infrastructure...<p>My hard line opinion is that if something NEEDS state management to exist and update, it&#x27;s a pet, treat it like a pet. Don&#x27;t mix pets with the rest of your automated machinery except to the minimum extent required, when absolutely necessary.<p>We had to rewrite an Ansible role because a patch level version upgrade on the recommended community package started destroying security groups... Another time we had to roll back our deployment Ansible image and update 30 repos because a minor level version bump in another Ansible recommended package suddenly required log groups to have an expiration value set in AWS or the module fell over with an null reference on the AWS lookup&#x2F;comparison... So we couldn&#x27;t use the latest version to fix it.<p>I&#x27;ve almost never had this happen with any AWS tool... Sure, there&#x27;s drift possibilities, but those are controllable by mainly not letting humans do things, and not having multiple cooks in the kitchen changing things in automation, which are good ideas for terraform and Ansible to...<p>I also encourage modular designs, any of which (except cdn&#x2F;db, and dns related stuff, in my use cases) can be torn down and re-built with only the brief outage nonexistence causes.. we only have done that once in 3 years, and we believe the issue was actually on AWS&#x27;s internal side anyways.<p>I&#x27;ve spun up over 260,000 vms over 4-5 years with one cloud formation template and the basic SDK call, and we&#x27;ve never bothered to convert it to another tool because it&#x27;s never broken.. we occasionally tweak it, use gp3 instead of gp2, etc, but it&#x27;s never needed us to unexpectedly side track a sprint for 1-3 days