I completely agree that it has problems. I use terraform a lot. Compared to nothing, I love terraform. However, it's so overwrought that it has to be hidden from anyone not in infra for a living.
1. IaC description should be format agnostic and transformable (eg definable in yaml, json, whatever).
2. Something about provider interfaces here, but it's already super messy and not sure if it's an improvement or just a shift
3. State files were wild west last time I checked. And there should be a default database interface provider at minimum. Maybe there is now?
4. Forcing the apply->statefile cycle as the default requires all of compute, interface, and a human. This should have been an abstraction on a raw interface for automated use.
While I agree with you about TF having a lot of issues, the comment isn't helpful. What would you suggest otherwise? Kind of a moot point now that the license is fubar'd, but what could be improved to make it better? If you could have a do-over, what would that look like?
Right now there is pulumi as a alternative that supports different clouds. Otherwise AWS CDK or Azure Bicep come to mind.
If i could to a do-over I'd want the solution to look and feel like AWS CDK but without the cloudformation in the background, and support for GCP and Azure.
I've worked with CDK for 2 years now and being able to define your code in Typescript is quite handy and drastically reduces the effort it takes for new people to learn how our deployment work. It's also quite nice to be able to directly bundle and deploy the application together with the infrascructure with very little effort.
How? I've always viewed TF as good at anything except metal; the best I would know to do is remote-exec but at that point you might as well drop to raw shell.
I mean that the only way I can think to use terraform to provision bare metal is to remote-exec a shell script (ex. to `apt install foo`), at which point you might as well skip terraform and `ssh targethost apt install foo` or `scp ./my-install-commands.sh root@targethost: && ssh root@targethost sh my-install-commands.sh`
1. IaC description should be format agnostic and transformable (eg definable in yaml, json, whatever).
2. Something about provider interfaces here, but it's already super messy and not sure if it's an improvement or just a shift
3. State files were wild west last time I checked. And there should be a default database interface provider at minimum. Maybe there is now?
4. Forcing the apply->statefile cycle as the default requires all of compute, interface, and a human. This should have been an abstraction on a raw interface for automated use.