What concerns me somewhat about Pulumi is we will lose some of "standardization" that comes with the widespread use of Terraform.
Like anything else, it is possible to write Terraform in an incomprehensible way. However, overall I have found that Terraform "constricts" things into being done a certain way. This allows engineers to jump into a new TF codebase and grok what is happening fairly easily.
Now with Pulumi, we lose that constraint, and now have to grok not only the different languages that infra is defined in, but also the wide variety of different "styles" that a language can be written in. An engineer joining from another company or team now has to deal with a new language and a new code style/organization in order to wrap their head around the infra. Not a desirable property when it comes to managing the infrastructure for a company.
While it is appealing that a developer can use a language they are already familiar with to manage infra, that only holds true if the language being used for Pulumi is one they are already familiar with.
I could of course be totally wrong. Regardless, I am excited to see a new contender in the space.
And Terraform doesn't even support declarative configuration management!!! The syntax is declarative, but it literally can not change the infrastructure to be the way you describe, if it has changed outside your state file (which can happen at literally any time).
Yep, which is why in the comment you replied to I said: "Like anything else, it is possible to write Terraform in an incomprehensible way.". You can write muck in anything.
Also, an hour sounds like a pretty reasonable amount of time to grok a totally new codebase of any significant complexity, but maybe I'm just slow. I can assure you that trying to grok the equivalent mess in a language and style you have never worked in before isn't going to be any faster.
> And Terraform doesn't even support declarative configuration management!!! The syntax is declarative, but it literally can not change the infrastructure to be the way you describe, if it has changed outside your state file (which can happen at literally any time).
I'm not sure what you mean by this. The first thing Terraform does before a plan or apply is refresh the state file with the real-world status of resources.
The simplest is if you start renaming modules or moving resources in and out of different modules. Terraform will get confused and try to destroy everything rather than modify in place, even though it's the same resource, or it will sometimes just fail altogether, like it's trying to resolve some module that used to exist but no longer exists. Basically it doesn't comprehend that its logical resources are really real-world things, and leans so heavily on its logical mapping (based on things like module inheritance, which is a Terraform logic thing, not a real-world AWS resource thing) that it often just becomes unusable, and you have to perform heroics of moving about pieces of code and importing various things to work around it, if it works at all.
The bigger problem is when you have a resource which might be associated with another resource, like the various ways to represent IAM policies and roles in terraform resources. You can create the resource one way and deploy it, and then maybe someone modifies the existing real-world resource in a way that now depends on some other resource... but that resource isn't in a Terraform file. Terraform doesn't know what to do, so it will either clobber the modified state, or just die because it doesn't know how to resolve the conflict.
I would need to go back and curate a list of all the times that Terraform has just failed to do anything because something changed that it didn't expect, but basically it refuses to "fix" things that are unexpected. That, and the lack of automatic importing of existing resources is just absurd.... If Terraformer can make it work, Terraform could have too.