Terraform Pain Points - Jonathan Bergknoff

`state mv` can’t do it). Moving across state boundaries is harder still. While the documentation mentions moving to a different state file, there’s no support for hooking it up to an already-existing state in S3 (for example). The tool is not at all user friendly or convenient. The silver lining is that Terraform state is a simple JSON file, so it’s easy to write your own tooling around it. My team had occasion to do several refactors where we pulled individual projects’ resources out of a monolithic state and into their own states, once for each of our environments. Trying to orchestrate that with … Terraform’s `merge()` only performs a shallow merge. This is surprising behavior, and can lead to subtle bugs. You can work around it if you know about it, but the workarounds are often awkward. There’s an open PR adding a `deepmerge()` function. When anything in the map is “not known until after apply” (e.g. an attribute of a resource that hasn’t been created yet), the entire map is considered “not known until after apply”. For example, if our config map looks like … Had Terraform used an established programming language instead of HCL, maybe this time would have been spent on pushing the infrastructure-as-code ecosystem forward. As it is, Terraform’s core is developed slowly and there don’t seem to be any meaningful innovations on the horizon. The AWS provider has a rapid pace of development, seeing a release approximately once a week. However, there are many long-standing PRs, fixing important bugs and adding important features, which languish for months with no attention from maintainers (example, example, example, example, example). It’s a good project, but apparently not particularly well managed.