Why Does Destroying Resources via TF Suck?

Cloud providers in general haven't gone very far toward providing hooks for validation.

It seems easier for the cloud provider to implement the equivalent of a dry-run flag in API calls that validate that the call would succeed (even if it's best effort determination) which could be used by tools like Terraform during the planning and dependency tree generation.

Instead, you have platform providers like AzureRM that squint at the supplied objects and make a guess as to whether that looks valid, which causes a ton of failures upon actual application. For instance, if you try to create storage with a redundancy level not supported by the region you're adding it to, Terraform will pass a plan stage, but the actual application of the resource will fail because the region doesn't support that level of redundancy.

There are unlimited other examples in a similar vein, all of which could be resolved if API providers had a dryrun flag.

I am not a fan of abreviations, this article didn't even have terraform written out once.

The most confusing part of terraform for me is that terraform's view of the infrastructure is a singleton config file that is often stored in that very infrastructure. And then you have to share that somehow with your team and be very careful that no one gets it out of sync.

Why don't cloud providers have a nice way for tools like TF to query the current state of the infra? Maybe they do and I'm doing IaC wrong?

Most tools, frameworks and articles in IT, SaaS in particular, are about spinning up things. It is what people find exciting.

Work a few years in Ops and you learn that spinning up things is not a big part of your work. It's maintenance, such as deleting stuff.

Unfortunately this process is the hardest, and there's very little to help you do it right. Many tools, framework and vendors don't even have proper support for it.

Some even recommend 'rinse and repeat' instead of adjusting what you have - and this method is not great if you value uptime, nor if you have state that you want to preserve, such as customer data :-)

Deleting stuff, shutting services down, turning off servers - those are hard tasks in IT.

I love how terraform can describe what I’ve got. Sort of. Assuming I or my colleagues or my noob customers don’t modify resources on the same account.

I don’t love how unreliable providers are, even for creating resources. Clouds like DigitalOcean will 429 throttle me for making too many plans in a row with only 100+ resources. Sometimes the plan goes through, but the apply fails. Sometimes halfway through.

I’d rather use a cloud-specific API, unless I’m certain of the quality of the specific terraform provider.

"Because referential integrity is a thing, and if you don't have all dependencies either explicitly declared or implicitly determinable in your plan, your cloud provider is going to enforce it for you."

Because TF is lacking sequentials state descriptions in rare cases - ex: Termination protections in AWS.

Hell, let's talk about why ^c'ing the plan phase sucks.