It makes sense if you consider how poor K8s' design already is. They somehow made it overcomplicated, yet lacking in critical features, with terrible security, no multitenancy, unnecessarily duplicated concepts, confusing and redundant configuration, a nightmarish setup process, no VCS integration, with mutable state, and lock-in reliance on specific external software components, while also having microservices, when the components were never really intended to be replaced, and misbehave when their assumptions change between versions. Then they invented and sunsetted multiple iterations of the same concept (plugins, essentially), redesigned other concepts (Roles) without consolidating them, and decided long-term support/stable ABIs are for chumps, so that anyone using it was stuck doing infinite migrations. It's up there with Jenkins and Terraform as one of the worst designed systems I've seen. The fact that you need a million integrations to make it do anything useful at scale is proof that it's more of a development toy than a practical tool.
You don’t like terraform? The version churn and things like the .lock file are pains in the ass, but overall it’s gotten pretty elegant and well documented.
Google "terraform wrapper". Terraform's interface is so bad that a million people have written their own interface to deal with how terrible Terraform's is. Most people settled on Terragrunt, but in some ways that's actually worse (DRY configuration is actually impossible with Terragrunt; I wrote my own wrapper (https://github.com/pwillis-els/terraformsh) to fix that problem).
Terraform's design is that of a half-baked configuration management program. It's not even declarative programming, because declarative programming requires the program actually try to achieve the desired end state. Terraform won't do that. It will try to create or destroy something based on what it thinks the world looks like, rather than what the world actually looks like. If anything is inconsistent, it simply dies, rather than try to fix or work around the inconsistency. Which is the opposite of what configuration management is supposed to do. It's supposed to fix the system state, not run away crying. In many ways, Puppet, Chef or even (ugh) Ansible would be better than Terraform at handling infrastructure state.
For example, if you tell Terraform you want an S3 bucket, and it tries to create one, but it already exists, Terraform dies. In that case they want you to manually use an 'import' command to import the existing S3 bucket (which btw is a different syntax for every single resource). Why doesn't it automatically import resources? Hashicorp's "philosophy" is that automation is bad and why would we want a computer to make a human's life easier when we can make the human serve the computer? This basic but critical feature is so important that Google created an entire project dedicated to it, called Terraformer.
If you write some Terraform HCL, you may be able to create your resources with it. But it's also very likely Terraform will not be able to change or destroy those same resources. Every provider has its own rules about what you can do with a resource, and none of those providers are required to apply those rules throughout the resource's lifecycle. So you deploy something to prod, and then need to change it, only to find out that change is impossible, half way through a terraform apply in production. Leaving you with broken production infrastructure. Many provider resources also have rules that require you to add a Terraform lifecycle policy, or it will be impossible to create, destroy, rename, etc a resource. Rather than make those lifecycle policies the default for a given resource, Terraform requires you to know in advance that that resource requires that lifecycle policy and to add it to every instance of that resource. But it will cheerfully create resources without the policy, with a big gaping hole in the floor waiting for your infra to fall through when you next make a change.
This is a very brief list of the insane stupidity that is Terraform. A blindfolded configuration management tool that can't handle changes and doesn't like automation, validation, or sane defaults.
> Terraform's design is that of a half-baked configuration management program. It's not even declarative programming, because declarative programming requires the program actually try to achieve the desired end state.
terraform is fully declarative; if I want a thing of the XYZ kind, I ask terraform «give me a thing of the XYZ kind and I don't care about how you will get it for me». Declarative programming operates with intentions without focusing on details of how the intention will actually be expressed; «give me XYZ» is an example of such an intention.
Declarative programming and the «desired end state» are orthogonal, and the desired end state may or may not even be the goal of a declarative program. For example, expert systems are all declarative, and they don't deal with «worlds» and can be «entered into» from «anywhere». And, since their «worlds» keep on constantly changing by introducing or retracting facts, at best it is only possible to think about a snapshot of such a world at a given moment in time.
> Terraform won't do that. It will try to create or destroy something based on what it thinks the world looks like, rather than what the world actually looks like.
Can you unpack that? terraform keeps the current state of «world» as a dependency graph in a state file and compares it with intentions expressed in .tf file(s) that under the hood translate into one or more new or changed graph nodes. If there are differences in two dependency graphs, it modifies the current in-memory dependency graph, applies changes to the infrastructure and incrementally updates the state file to reflect the dependency graph update progression in the infrastructure.
terraform is not a sentient being, therefore it can't solve philosophical problems nor can it reason about anything that goes beyond its state file. It is, essentially, a «make» for the infrastructure management with each provider supplying built-in build rules.
> For example, if you tell Terraform you want an S3 bucket, and it tries to create one, but it already exists, Terraform dies. In that case they want you to manually use an 'import' command to import the existing S3 bucket (which btw is a different syntax for every single resource). Why doesn't it automatically import resources?
Why? Because it is a feature.
If a S3 bucket already exists, it may mean of the following:
1. It is already managed by another terraform project;
2. It has another owner who might have created it using a different tool that manages the S3 bucket lifecycle differently;
3. A coding mistake, e.g. a .tf file has been copied and pasted into;
4. Something else.
If terraform were to be allowed to auto-import existing resources, case (1) would become a time ticking bomb until the S3 bucket would get updated by another run of a terraform project that manages it as well; case (2) would likely result in a homicide with the rightful S3 bucket owner chasing you around with a hammer; case (3) is a wake-up call to not rampantly copy and paste .tf files; case (4) can be anything else.
