www.schibsted.pl
9 reasons why terraform is a pain, and 1 why you should still care - Schibsted Tech Polska
## The pains ### 1. The evil state First thing you will complain about, when it comes to Terraform, is the fact that it’s stateful, and the implications it brings. I personally consider two issues that it brings: - the state has to be in sync with the infrastructure all the time – that also means that you have to go all-in when it comes to provisioning – i.e. no stack modifications can be made outside of the provisioning tool - you have to keep the state somewhere – and this has to be a secure location as state has to carry secrets … ### 2. Hard to start with the existing stack Back in the early days of Terraform, its issue tracker was full of complaints from people not being able to leverage Terraform with the existing stack. The reason for it was the fact, that Terraform was not able to incorporate it into the state (to my amazement, while looking for a sign of this, I’ve found my old PR that was trying to address that issue back then 😉 ). Fortunately, the import command was introduced, and this problem has been solved (at least at the system level). … ### 3. Complicated state modifications There is one additional thing that is a bit problematic when dealing with the state. While constantly refactoring your infrastructure definition, you may end up renaming resources (changing their identifiers) or moving them deeper into modules. Such changes are unfortunately hard for Terraform to follow, and leave it in a state where it doesn’t know that certain resources are simply misplaced. If you run … ### 4. Tricky conditional logic There are some people around the web who doesn’t like the fact that Terraform is not really an actual imperative programming language. To be perfectly honest I don’t share that opinion – I think the provisioning definition of the stack should be as declarative as it can – that leaves a lot less space for some deviations in the definitions. On the other hand, the conditional logic provided by Terraform is a bit tricky. For example to define a resource that is conditionally provisioned you make the resource to be a list, and use the count parameter to control it:
Related Pain Points5件
Sensitive data exposure in state and plan artifacts
9Terraform stores real secret values (API tokens, database passwords) in plaintext state files and plan output despite showing (sensitive value) in the CLI. When plan files are uploaded as CI/CD artifacts, they become security liabilities if accessible to unauthorized parties.
State refactoring and cross-boundary resource moves lack tooling support
7Moving resources between state files or across state boundaries is not supported by terraform mv or other built-in tools. Teams must manually edit JSON state files or write custom tooling to reorganize infrastructure across projects or environments.
Terraform state drift from manual cloud console changes
7Teams circumvent Terraform workflows by making changes directly in cloud provider consoles, causing state files to become out of sync with actual infrastructure. This drift prevents accurate planning and can lead to unexpected behavior during subsequent Terraform operations.
Difficulty incorporating existing infrastructure into Terraform
7Terraform users struggle to bring existing infrastructure stacks under management because Terraform cannot automatically incorporate them into its state without manual intervention.
HCL syntax is awkward and creates steep onboarding curve
5The Terraform configuration language (HCL) is unintuitive compared to standard programming languages. Concepts like conditional logic, looping with for_each, and mapping collections are unnecessarily cumbersome. Few developers have deep Terraform experience, slowing team onboarding.