TF can be often suffocating still. Pulumi runs circles around it, when it comes to user experience in writing complex, modular, composable and reusable configurations.
Their okta provider, for example, is based on some absolutely ancient, non-standard provider (https://github.com/pulumi/pulumi-okta/blob/v2.1.2/provider/g... ) instead of using the official one which receives regular updates: https://github.com/terraform-providers/terraform-provider-ok... ; and now I guess it's on me to do some git diff to find out if there are meaningful changes between the imported provider and the upstream one?
To say nothing of the more esoteric providers that one can cheaply build and place in the `.terraform.d/plugins` directory and off you go, in contrast to trying to find the dark magick required to use some combination of https://github.com/pulumi/pulumi-terraform-bridge and https://github.com/pulumi/pulumi-tf-provider-boilerplate but ... err, ... then one has to own that new generated pulumi provider code? So like a fork but worse? Maybe they should make a bot that tracks the terraform-provider topic on GH and uses their insider knowledge to generate pulumi providers for them.
Don't get me wrong: I anxiously await the death of TF, but until there is a good story to tell my colleagues about an alternative to it, they'll continue to use it.
I'd rather learn Go than deal with JavaScript. Python would be fine. Elixir would be great (I'd much prefer Erlang but there are only so many miracles I'm allotted in this lifetime). Perl, please.
I never understand when people say operators don't like programming languages. Always seems weird to me that a person that constantly works with computers would prefer a static markup language instead of full programming language for managing the complexity of operating software in production environments.
My original comment was about this attitude. I personally think programming languages are much better than markup languages for almost everything. If you are presenting static content then markup languages are fine but if you're doing anything more than presenting static content then YAML just makes no sense.
A person who constantly works with computers is painfully aware of the people's ability to screw things up by an honest mistake when programming them. The more complex the thing, the easier it is to make a mistake, because human attention is finite.
Whenever you can limit the language to the task at hand, and build in guard rails that would prevent you from doing things you should not be doing, it's usually a productivity win, even if it precludes implementation of 3% of some most advanced and complex solutions. Reliability and simplicity go hand in hand, and reliability is often the thing devops people value very highly.
The solution to finite attention isn't less powerful tools. The solution is more powerful tools that augment operators and let them extend their finite attention spans into longer time horizons.
How is your description and viewpoint different from what I just described?
What I won't like is the "here are some classes and functions for accessing our API, go build the stuff somehow" approach.
And it makes sense. As we demand more flexibility to not repeat ourselves (DRY) we get clever and add little features.
Suddenly you can stick an entire cluster config (or several!!) inside a lambda that returns the declared resources... And you've gone straight to hell. You're more than Turing complete by then and engineers are reinventing conditionals and loops with lambdas all over your config codebase.
Might as well have just started and left it at Python/etc.
Disclaimer: I worked on Terraform at HashiCorp and am a contributor to Pulumi also.
Really dig using with it Cloud Run.
Pulumi has two different k8s modules, the standard one (pulumi-kubernetes) and "kubernetes-x" which has a much nicer API that reduces boilerplate:
https://github.com/pulumi/pulumi-kubernetesx
The second one doesn't seem to be used in the Pulumi tutorial content and has less stars/recognition.
Are these interchangeable? If so, why not use @pulumi/kubernetesx instead of the standard k8s module everywhere?
To my mind, the real power of having general purpose languages building the declarative model instead of a DSL is that libraries like k-x (or indeed AWS-x) can actually be built!