4 ms·

I really prefer the Pulumi approach where you define the configuration in your favorite Turing-complete language. Not sure why Hashicorp felt the need to reinv

by jchook 5y ago

I really prefer the Pulumi approach where you define the configuration in your favorite Turing-complete language. Not sure why Hashicorp felt the need to reinvent the wheel instead of having a library in an existing language generate markup or JSON or something like that.

solatic 5y ago
The biggest issue with Pulumi is that Pulumi doesn't support adding custom API providers. Part of the power of Terraform is in provisioning infrastructure, orchestration, deployment, and application configuration all in one tool. For example: (aforementioned GitHub provider) https://registry.terraform.io/providers/terraform-provider-concourse/concourse/latest/docs https://registry.terraform.io/providers/terraform-provider-c... for Concourse (CI/CD) https://registry.terraform.io/providers/coralogix/coralogix/latest https://registry.terraform.io/providers/coralogix/coralogix/... (full disclosure: I work for Coralogix) This would be completely impossible with Pulumi. If Pulumi didn't bless it, it doesn't exist in Pulumi's world. In the meantime, Terraform allows you to separate all the network calls to a custom provider and allow you to just focus on the configuration. The number of paid external APIs is only expanding exponentially, Pulumi can't possibly build and support them all in-house. Sounds like a current limitation of Pulumi's "use any programming language you want" design and something that really needs to be addressed; it's not that writing a custom Terraform provider is easy, but it is quite simple to get started by following any of the bajillion open-source providers as a sample template to get started from.
- mdaniel 5y ago
  > If Pulumi didn't bless it, it doesn't exist in Pulumi's world. That has not been my experience. I have personally ported a Sentry TF provider into Pulumi, and I will grant you that their docs and examples are bordering on active user hatred for exercising the process, but it does work: https://github.com/pulumi/pulumi-terraform-bridge#adapting-a-new-terraform-provider https://github.com/pulumi/pulumi-terraform-bridge#adapting-a... https://github.com/pulumi/pulumi-tf-provider-boilerplate#readme https://github.com/pulumi/pulumi-tf-provider-boilerplate#rea... What mystifies me about that situation is that I do actually appreciate the amount of silliness that is required to avoid using Pulumi cloud: they are not financially incentivized to make that easy, but I'd guess a lot more folks would nope right out if they didn't make it possible However, I would think they'd want to make ingesting a TF provider into Pulumi as smooth and reliable as possible, so they don't have people close their browser tab when they don't find a supported provider for Pulumi but it exists in TF
- __jem 5y ago
  Maybe I’m missing something, but I don’t think this is true? E.g., https://www.pulumi.com/blog/dynamic-providers/ https://www.pulumi.com/blog/dynamic-providers/ There’s also an example of their blog on doing a schema migration with custom logic.
- TrueTeller 5y ago
  (Pulumi providers dev here) This has been the case in the past but we are investing in our provider ecosystem. We built several first-party native providers that aren't based on TF: Kubernetes, Azure, Google. Now, we also encourage third-parties to build their integrations. Here is a boilerplate repo of a resource-based provider: https://github.com/mikhailshilkov/pulumi-provider-boilerplate https://github.com/mikhailshilkov/pulumi-provider-boilerplat... Here is a provider that is driven by an Open API spec: https://github.com/mikhailshilkov/pulumi-provider-boilerplate-openapi https://github.com/mikhailshilkov/pulumi-provider-boilerplat... For simple use-cases, you've always been able to build Dynamic Providers in TypeScript or Python: https://www.pulumi.com/blog/dynamic-providers/ https://www.pulumi.com/blog/dynamic-providers/ Please reach out if you want to build a provider and we'll definitely help you out.
- hacker_newz 5y ago
  Why are you using Terraform for orchestration?
- jen20 5y ago
  > This would be completely impossible with Pulumi. If Pulumi didn't bless it, it doesn't exist in Pulumi's world. This is only true (temporarily) for automatic plug-in installation - and was until recently also true of Terraform. In fact I had to reverse engineer the TF provider registry protocol because the documentation is manifestly incorrect, recently. $WORK has lots of Pulumi plug-ins which they know nothing of the existence of, and it works fine.
jaaames 5y ago
Can't agree enough. Declarative programming makes sense for lots of things, React is a great example. With such a big dependency graph for infra, adding loops and variables and templating to be able to achieve the same thing as Pulumi in a "declarative" way is ultimately just harder and worse than using a familiar powerful language with an SDK.
- jen20 5y ago
  Worth noting that Pulumi IS declarative - the languages build a graph imperatively, but the evaluation is declarative in nature.

by jchook 5y ago

solatic 5y ago

The biggest issue with Pulumi is that Pulumi doesn't support adding custom API providers. Part of the power of Terraform is in provisioning infrastructure, orchestration, deployment, and application configuration all in one tool. For example: (aforementioned GitHub provider) https://registry.terraform.io/providers/terraform-provider-concourse/concourse/latest/docs https://registry.terraform.io/providers/terraform-provider-c... for Concourse (CI/CD) https://registry.terraform.io/providers/coralogix/coralogix/latest https://registry.terraform.io/providers/coralogix/coralogix/... (full disclosure: I work for Coralogix) This would be completely impossible with Pulumi. If Pulumi didn't bless it, it doesn't exist in Pulumi's world. In the meantime, Terraform allows you to separate all the network calls to a custom provider and allow you to just focus on the configuration. The number of paid external APIs is only expanding exponentially, Pulumi can't possibly build and support them all in-house. Sounds like a current limitation of Pulumi's "use any programming language you want" design and something that really needs to be addressed; it's not that writing a custom Terraform provider is easy, but it is quite simple to get started by following any of the bajillion open-source providers as a sample template to get started from.

mdaniel 5y ago
> If Pulumi didn't bless it, it doesn't exist in Pulumi's world. That has not been my experience. I have personally ported a Sentry TF provider into Pulumi, and I will grant you that their docs and examples are bordering on active user hatred for exercising the process, but it does work: https://github.com/pulumi/pulumi-terraform-bridge#adapting-a-new-terraform-provider https://github.com/pulumi/pulumi-terraform-bridge#adapting-a... https://github.com/pulumi/pulumi-tf-provider-boilerplate#readme https://github.com/pulumi/pulumi-tf-provider-boilerplate#rea... What mystifies me about that situation is that I do actually appreciate the amount of silliness that is required to avoid using Pulumi cloud: they are not financially incentivized to make that easy, but I'd guess a lot more folks would nope right out if they didn't make it possible However, I would think they'd want to make ingesting a TF provider into Pulumi as smooth and reliable as possible, so they don't have people close their browser tab when they don't find a supported provider for Pulumi but it exists in TF
__jem 5y ago
Maybe I’m missing something, but I don’t think this is true? E.g., https://www.pulumi.com/blog/dynamic-providers/ https://www.pulumi.com/blog/dynamic-providers/ There’s also an example of their blog on doing a schema migration with custom logic.
TrueTeller 5y ago
(Pulumi providers dev here) This has been the case in the past but we are investing in our provider ecosystem. We built several first-party native providers that aren't based on TF: Kubernetes, Azure, Google. Now, we also encourage third-parties to build their integrations. Here is a boilerplate repo of a resource-based provider: https://github.com/mikhailshilkov/pulumi-provider-boilerplate https://github.com/mikhailshilkov/pulumi-provider-boilerplat... Here is a provider that is driven by an Open API spec: https://github.com/mikhailshilkov/pulumi-provider-boilerplate-openapi https://github.com/mikhailshilkov/pulumi-provider-boilerplat... For simple use-cases, you've always been able to build Dynamic Providers in TypeScript or Python: https://www.pulumi.com/blog/dynamic-providers/ https://www.pulumi.com/blog/dynamic-providers/ Please reach out if you want to build a provider and we'll definitely help you out.
hacker_newz 5y ago
Why are you using Terraform for orchestration?
jen20 5y ago
> This would be completely impossible with Pulumi. If Pulumi didn't bless it, it doesn't exist in Pulumi's world. This is only true (temporarily) for automatic plug-in installation - and was until recently also true of Terraform. In fact I had to reverse engineer the TF provider registry protocol because the documentation is manifestly incorrect, recently. $WORK has lots of Pulumi plug-ins which they know nothing of the existence of, and it works fine.

jaaames 5y ago

Can't agree enough. Declarative programming makes sense for lots of things, React is a great example. With such a big dependency graph for infra, adding loops and variables and templating to be able to achieve the same thing as Pulumi in a "declarative" way is ultimately just harder and worse than using a familiar powerful language with an SDK.

jen20 5y ago
Worth noting that Pulumi IS declarative - the languages build a graph imperatively, but the evaluation is declarative in nature.