First of all, building a provider isn't straightforward. The best way I've found to do this is to wrap `terraform init`, and have it `docker run` a build process for a plugin version that never existed - then dumping the built provider into the `.terraform` directory for the project. It's prone to failure; new users of the Terraform project complain that the build eats 8GB of RAM and takes many minutes.
Second, providers are constantly changing, and it's not always possible to cleanly rebase a set of community changes on top of master. Part of the trouble with letting PRs wither on the vine is that they themselves become stale - in one case, the code still compiles, but the end result is completely wrong.
For what it's worth: my use case was needing to use Terraform with some more "unusual" features of CloudFront and ALBs. The 80% use case for support is great. There's a remaining 15% that's well implemented by unmerged PRs, and another 5% entirely that's completely unsuppored. I've kept it IaC by using the `null_resource` provisioner to shell out to the AWS CLI where absolutely necessary.
heh. i've been considering a switch from ansible to terraform because i've been frustrated by ansible's limited support for some of the edge cases around ALBs. good to hear that terraform also sucks.
i'm gradually coming to the conclusion that all the tools that are supposed to make provisioning cloud infrastructure easier aren't as good as a bunch of crappy custom scripts using boto or aws-cli.
Terraform is a massive improvement over Ansible if you do anything non-trivial; even if it sucks, it sucks significantly less than Ansible at managing infrastructure resources.
I sometimes fool myself into thinking I can use Ansible in simple cases and that Terraform would be overkill but so far I've regretted those decisions every time.
Ansible is sort of bad at everything, and does a few things decently.
I use it as an orchestrator / clusterssh replacement, but for configuration management it makes me nervous because I can't trust it to just not break for stupid reasons.
Last time I used it on Amazon Linux 2 with packer. It worked, but 1/3 of the time it failed with some strange error about yum database corruption.
I suspect what was happening is that Amazon Linux on start run yum to apply all available updates, and ansible was not respect yum locks, which is very surprising given that Ansible came from Red Hat so they should have known how important locking is for yum.
I ended up using salt (which has its own set of issues) and never looked back.
One big difference here is that while the tools might all depend on the SDK provided by the cloud, the tools themselves can also do a whole lot of good/wrong on their side. Terraform fixes a lot of that by delivering a 'standard' provider interface with normalised data formats, resource structures and encapsulation. That was pretty much a requirement for the tool to work anyway, otherwise it wouldn't have a unified way to check for configuration drift, plan changes, apply changes, do cleanups etc. You also wouldn't be able to pass data around easily (you'd end up shuffling strings around instead).
Some people prefer to do the CDK thing where you use a general programming language to synthesise the IaC stuff and then run it that way, but that doesn't really fix anything because a CDK is just built on top of the same SDK. As an added insult to injury, you now don't have a domain-specific language so save you from yourself (and your team) with all the anti-patterns you now have at your disposal ;-)
You can sideload Terraform providers so you don't need to do this. I personally recommend the [implicit local mirror directory](https://www.terraform.io/docs/cli/config/config-file.html#im...) where you just place your provider in your OS's respective Terraform plugin directory (MacOS: `$HOME/.terraform.d/plugins/`).
There's other ways to sideload providers on that docs page too
First of all, building a provider isn't straightforward. The best way I've found to do this is to wrap `terraform init`, and have it `docker run` a build process for a plugin version that never existed - then dumping the built provider into the `.terraform` directory for the project. It's prone to failure; new users of the Terraform project complain that the build eats 8GB of RAM and takes many minutes.
Second, providers are constantly changing, and it's not always possible to cleanly rebase a set of community changes on top of master. Part of the trouble with letting PRs wither on the vine is that they themselves become stale - in one case, the code still compiles, but the end result is completely wrong.
For what it's worth: my use case was needing to use Terraform with some more "unusual" features of CloudFront and ALBs. The 80% use case for support is great. There's a remaining 15% that's well implemented by unmerged PRs, and another 5% entirely that's completely unsuppored. I've kept it IaC by using the `null_resource` provisioner to shell out to the AWS CLI where absolutely necessary.