Things that are wrong with Terraform

Warren Parad
3 min readJan 9, 2021

Just writing down my list of things that are problematic with TF. While you don’t have agree, it’s good to put the list down and begin that conversation.

  • Ooof! If you want to upgrade, Terraform constantly breaks syntax functionality between versions, and it might even change how your state files are configured, that means every single version upgrade might require a full rewrite just to do the one version change. Now do this for every version. Or you could just bite the bullet and say, we can never use the new features of Terraform that we desperately need, because unlike Pulumi or CloudFormation, it doesn’t have full languages support out of the box.
  • Suggested formatting rules => bad for vcs diffs
  • doesn’t support multiple environments well
  • No conditional resources!
  • syntax is over complicated (makes it also very easy to do the wrong thing)
  • docs are highly inconsistent with actual platform terminology
  • docs are riddled with Warnings and notes: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/security_group and that’s the best case scenario if they are well documented providers.
  • It creates pit of failure by coupling usage of resources to arbitrary values. Such as forcing you to use GCP Zone Name instead of the DNS name (Zone names should be irrelevant and yet they now are super critical): https://registry.terraform.io/providers/hashicorp/google/latest/docs/data-sources/dns_managed_zone
  • abuses parameters to do different things making it easy to get it wrong
  • logging is verbose but unhelpful
  • easy to get a provider or change logic corrupting your stack
  • Stack requires S3 bucket or account with hashicorp, so impossible to use platform providers tools to understand groupings. For instance with CFN you can just see what’s in the stack.
  • Easy to break your state file and cause corruption, you will have write commands to fix the state file when it breaks.
  • If Terraform crashes while running then it doesn’t understand what it started doing (from the beginning). That’s terraform, CI/CD crashing, or credentials expiring during the run. That’s because terraform doesn’t continuously write state, it waits all the way until the end.
  • updates do not follow SemVar
  • Providers don’t handle unexpected situations well if at all
  • Often and frequent workarounds to make changes to resources that haven’t been correctly developed (email unsupported in SNS: https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/sns_topic_subscription)
  • Veil of security when there is none, all your secrets and passwords are saved in the state file so any one with access can read them.
  • lack of first class provider support. CFN in AWS lets you integrate lambda functions with secrets in a secure way, TF can never have that. (Curious what I mean: First-Class secrets support)
  • unresponsive to bugs in TF, don’t merge Pull requests, don’t respond to issues. Frequently they’ll just close the issue after 30 days with no fix or suggestion.
  • You can’t patch bugs in TF in your own space. Like any normal library, you could simply copy out what you need or extend the existing functionality. With TF, nope! You can fork modules, but you don’t want to try to do the same with a provider, it’s head-exploding that TF HCL doesn’t support provider overrides and customization.
  • TF is not a service, let alone a first class one. Want to do something outside of terraform with the data that TF knows about. NOPE. You’ll likely be forced to using TF again in those other circumstances or exporting the data you need from the TF through a hacky process somewhere else to be reused.

--

--