I'm quite late to respond here, but just wanted to clarify one thing: Terraform is WORKFLOW agnostic, not TECHNOLOGY agnostic. This is a key part of our product philosophy that we make the 1st element of our Tao: https://www.hashicorp.com/tao-of-hashicorp
I don't think we've ever claimed cloud portability through "write once run anywhere;" that isn't our marketing or sales pitch and if we ever did make that claim please let me know and I'll poke some teams to correct it. Our pitch is always to just learn one workflow/tool and use it everywhere, but you explicitly WILL rewrite cloud-specific modules/code/etc.
With Terraform, the big win for folks is learning how to write and use Terraform, then knowing a fully supported official tool (to some extent) for hundreds of API-driveable systems. Instead of educating an engineer on CloudFormation, Azure ARM, etc. they learn ONE tool and ONE syntax and then adapt that to their cloud-specific knowledge.
More details are in the tweet I mentioned above, but I hope that helps. Fully respect you not being a fan of Terraform, I don't mind that, I just wanted to make sure for yourself and others reading that it is clear that we also don't believe Terraform is cloud agnostic in the sense you described.
I highly appreciate what Terraform does for me and the whole industry.
I also think sometimes why i don't like it very much and how i would make it different.
How the state is handled, including potential secrets in it, is just frustrating. Having root secrets for your whole setup exposed/unsecure is bad. The state is relativly fragile and cumbersome to clean up or fix. I also can't grasp that tf even needs a state and the cloud providers can't return the current state just fast enough. Only a lightweight cache would then be needed.
And probably due to implementation details, plans show sometimes changes when there would be no changes necessary.
For me its a good tradeoff to use terraform for setting up a k8s environment and then handling everything with ArgoCD.
Google Connector is a very great thought: you create a k8s resource and the cloud provider executes it for you on their cloud. No terraform needed anymore at all.
I also have to use Terraform and I try to avoid looking at it as much as possible. Hashicorp HCL is incredibly bad (not to use stronger words). I am trying to use an alternative like Pulumi whenever possible, but thankfully there is some hope with cdktf, since Terraform is today effectively technical debt.
I can't see how anyone thought that HCL, a terrible language to use in any aspect, was a better choice than a general purpose language like python or js. Every one in our infra org utterly despises HCL.
The workflow or Terraform is also very poor, it promotes bad practices and does not offer decent guarantees.
I know I sound harsh, but I hope it is received as constructive criticism
I'm quite late to respond here, but just wanted to clarify one thing: Terraform is WORKFLOW agnostic, not TECHNOLOGY agnostic. This is a key part of our product philosophy that we make the 1st element of our Tao: https://www.hashicorp.com/tao-of-hashicorp
I've talked about this more with more references in this tweet: https://twitter.com/mitchellh/status/1078682765963350016
I don't think we've ever claimed cloud portability through "write once run anywhere;" that isn't our marketing or sales pitch and if we ever did make that claim please let me know and I'll poke some teams to correct it. Our pitch is always to just learn one workflow/tool and use it everywhere, but you explicitly WILL rewrite cloud-specific modules/code/etc.
With Terraform, the big win for folks is learning how to write and use Terraform, then knowing a fully supported official tool (to some extent) for hundreds of API-driveable systems. Instead of educating an engineer on CloudFormation, Azure ARM, etc. they learn ONE tool and ONE syntax and then adapt that to their cloud-specific knowledge.
More details are in the tweet I mentioned above, but I hope that helps. Fully respect you not being a fan of Terraform, I don't mind that, I just wanted to make sure for yourself and others reading that it is clear that we also don't believe Terraform is cloud agnostic in the sense you described.