Terraform, as an idea, is brilliant. Mitchell and company isolated a hugely important need and tried to fill it, and I give them all the credit in the world for that. Cross-platform cloud provisioning? Gimme. But I cannot in good conscience not relate what a disastrous experience Terraform has been for me at both jobs and clients.<p>Writing reusable code in Terraform is an exercise in frustration due to the extreme clumsiness of HCL (which, I understand, was used because &quot;YAML is complicated&quot;--well, that&#x27;s true, but YAML isn&#x27;t a good solution either, you&#x27;re <i>HashiCorp</i>, you wrote <i>Vagrant</i>, you already know how to do this!). The application architecture is reckless and full of race conditions; your state <i>will</i> be hosed if one resource errors out at the wrong time, while other resources are being successfully updated--the resources that return successfully after the failed resource will on many occasions fail to be persisted to state.  What&#x27;s more, application testing seems to be at best an afterthought: there have been regressions in the providers that will break your <i>existing</i> states.<p>I would under no circumstances use Terraform if I didn&#x27;t have clients who had selected it before I was working with them. If in AWS, I would use CloudFormation, with a tool like Cfer[1] (which is excellent, reliable code) or SparkleFramework[2] (which is more full-featured but I hope you never need to debug it) to provision my stuff.<p>(Full disclosure: I&#x27;m building a much, much better provisioner for multi-provider cloud infrastructure. Neither of the projects I recommend are mine; mine&#x27;s not done yet.)<p>[1] - <a href="https:&#x2F;&#x2F;github.com&#x2F;seanedwards&#x2F;cfer" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;seanedwards&#x2F;cfer</a><p>[2] - <a href="http:&#x2F;&#x2F;www.sparkleformation.io&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.sparkleformation.io&#x2F;</a>