Things that are wrong with Terraform
Tags: cdk, terraform, iac, microservices
Published: 2021-06-07 14:44:19

---
title: Things that are wrong with Terraform
published: true
date: 2021-01-09 18:42:01 UTC
tags: cdk,terraform,iac,microservices
canonical_url: https://dev.to/wparad/things-that-are-wrong-with-terraform-g87
---

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.

## Production critical issues

* 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.

* easy to get a provider or change logic corrupting your stack

* 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.

## Poor Development Experience

* Suggested formatting rules => bad for vcs diffs
* doesn't support multiple environments well
* No conditional resources! You can abuse the system to jam a ternary into the `count`, but that creates a mess everywhere. and also jam it into the count statement
that is so awful, and then all your resources need to be references by `resource.name.[0].key`
* 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.
* logging is verbose but unhelpful

## Lots of resources are poorly designed
* 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

## Broken by design
* 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.

* 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.


* Stack requires S3 bucket or account with hashicorp, so impossible to use platform providers tools to understand groupings. For instance with AWS CloudFormation 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.

* updates do not follow SemVer, sure they say the do, same for the providers, but they don't. Which means upgrading will be sure to break your critical infrastructure. And in ways you will never expect nor be able to test for.

* 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.


* 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. You might be thinking about forking the repo and hosting it on github, but you are going to very soon find out about the signature security strategy for TF providers. I welcome you to test this out.

## Low ecosystem quality

* 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)

* lack of first class provider support. CloudFormation 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)


***
If you liked this article come join our [Security Community](https://authress.io/community) and discuss this and other devsecops related topics!