3 ms·

Terraform is just an overcomplicated way to call APIs. It's not deterministic and idempotent, as if you're "doing it right" you don't even know what values it's

Terraform is just an overcomplicated way to call APIs. It's not deterministic and idempotent, as if you're "doing it right" you don't even know what values it's going to apply until after it's applied them. It can't be idempotent because Terraform doesn't determine if an API call will succeed or fail or do the same thing or not, the SaaS API does. And if you change anything, it can trigger a destroy, a create-destroy, a destroy-create, a create, or a modify, all of which may fail if the provider's resource wasn't designed for that particular operation with those values, which you won't know until it actually happens. Debugging it is a nightmare, and the bizarre interaction with pretty shoddy and inconsistent providers makes it pretty lucky if your applies actually work. It's basically an annoying version of curl that has a DAG that you can't even make good use of. I wouldn't call it whimsical, but getting anything to work in Terraform consistently definitely requires serendipity.

mauflows 5y ago
> as if you're "doing it right" you don't even know what values it's going to apply until after it's applied them. It can't be idempotent because Terraform what do you mean by this? 'terraform apply' runs plan first, and tells me the diff from the expected state. Then it asks me if I want to reconcile it. I agree with the rest tho
- 0xbadcafebee 5y ago
  Have you seen it say "Old Value X" -> (known after apply) ? If you use most of Terraform's features, a good deal of the new values are (known after apply). If any of a value requires looking something up at apply time - say, from a backend, a data source, a local, the creation/modification/deletion of a different resource, a name_prefix, an internal function, etc - Terraform can't (or more precisely, won't) tell you what the new value is or could be. So often you have no idea what the result is going to be until it's done.
- lukevp 5y ago
  Not all values are known to you or terraform until after the apply. For example, on AWS, publishing a new version of lambda might have the ARN as known after apply since it includes the version # as part of the string. Or something like the calculated hash of an S3 object that would be known after apply. You can still reference these values in other parts of your terraform, and it will propagate the < ‘known after apply’ state there too. These dependencies are built into a graph to determine which items should be applied first, so all references to unknown data can be resolved in the correct order.
lukevp 5y ago
You’re correct in that it’s not deterministic or idempotent if the APIs are not, but this reads as very anti-terraform. The purpose is not to be easier than curl, but to express your infrastructure in code so you can check it into a project and automate the deployment process, keeping the code version of the infrastructure in line with what is deployed. Curl doesn’t do that in any way and isn’t at all a valid comparison to terraform. If you feel IaC as a whole is a pointless/useless endeavor, that’s a point to argue, but comparing terraform to curl in this way is ignoring the main value add of IaC.
- 0xbadcafebee 5y ago
  What do you mean curl doesn't do that? Terraform is literally just calling a REST API. Curl also just calls a REST API. #!/bin/sh curl -d '{"some key": "value here"}' -H "X-Some-Header: Foo-Bar" https://some-aws-domain/some/rest/api Put that in Git; now you have Infrastructure as Code. IaC is not some holy scepter ordained to us by God. It's literally just a version-controlled list of commands that call SaaS APIs. It's not special or magical. And Terraform doesn't do it any better than a bunch of curls in a shell script. The only reason to use Terraform is it's a standard way for a large group of people to make changes to the same thing. But if an entire team standardized on a shell script full of curls, that would work just as well. (Better, actually, because you could actually have error handling, auto-healing, importing existing resources, checking if they exist before trying to apply changes... you know, things that are useful for IaC that Terraform does not do)

mauflows 5y ago

> as if you're "doing it right" you don't even know what values it's going to apply until after it's applied them. It can't be idempotent because Terraform what do you mean by this? 'terraform apply' runs plan first, and tells me the diff from the expected state. Then it asks me if I want to reconcile it. I agree with the rest tho

0xbadcafebee 5y ago
Have you seen it say "Old Value X" -> (known after apply) ? If you use most of Terraform's features, a good deal of the new values are (known after apply). If any of a value requires looking something up at apply time - say, from a backend, a data source, a local, the creation/modification/deletion of a different resource, a name_prefix, an internal function, etc - Terraform can't (or more precisely, won't) tell you what the new value is or could be. So often you have no idea what the result is going to be until it's done.
lukevp 5y ago
Not all values are known to you or terraform until after the apply. For example, on AWS, publishing a new version of lambda might have the ARN as known after apply since it includes the version # as part of the string. Or something like the calculated hash of an S3 object that would be known after apply. You can still reference these values in other parts of your terraform, and it will propagate the < ‘known after apply’ state there too. These dependencies are built into a graph to determine which items should be applied first, so all references to unknown data can be resolved in the correct order.

lukevp 5y ago

You’re correct in that it’s not deterministic or idempotent if the APIs are not, but this reads as very anti-terraform. The purpose is not to be easier than curl, but to express your infrastructure in code so you can check it into a project and automate the deployment process, keeping the code version of the infrastructure in line with what is deployed. Curl doesn’t do that in any way and isn’t at all a valid comparison to terraform. If you feel IaC as a whole is a pointless/useless endeavor, that’s a point to argue, but comparing terraform to curl in this way is ignoring the main value add of IaC.

0xbadcafebee 5y ago
What do you mean curl doesn't do that? Terraform is literally just calling a REST API. Curl also just calls a REST API. #!/bin/sh curl -d '{"some key": "value here"}' -H "X-Some-Header: Foo-Bar" https://some-aws-domain/some/rest/api Put that in Git; now you have Infrastructure as Code. IaC is not some holy scepter ordained to us by God. It's literally just a version-controlled list of commands that call SaaS APIs. It's not special or magical. And Terraform doesn't do it any better than a bunch of curls in a shell script. The only reason to use Terraform is it's a standard way for a large group of people to make changes to the same thing. But if an entire team standardized on a shell script full of curls, that would work just as well. (Better, actually, because you could actually have error handling, auto-healing, importing existing resources, checking if they exist before trying to apply changes... you know, things that are useful for IaC that Terraform does not do)