What does HackerNews think of pulumi?

Pulumi - Universal Infrastructure as Code. Your Cloud, Your Language, Your Way 🚀

Language: Go

#7 in Amazon Web Services
#2 in Azure
#5 in C#
#4 in .NET
#33 in Go
#26 in Go
#3 in Terraform
#50 in JavaScript
#17 in Kubernetes
#61 in Python
#5 in Serverless
#20 in TypeScript
Rethinking Infrastructure as Code from Scratch | Jul 2023
neat! https://github.com/pulumi/pulumi
Ask HN: Who is hiring? (July 2023) | Jul 2023
Pulumi | Seattle and US + EU (Remote) | Full-time | Full Stack, Compilers, and Distributed Systems

Pulumi builds the tools for the cloud that developers deserve.

https://pulumi.com https://github.com/pulumi/pulumi

- Principal Compilers Engineer: https://boards.greenhouse.io/pulumicorporation/jobs/56227900...

- Principal Full Stack Engineer: https://boards.greenhouse.io/pulumicorporation/jobs/55482150...

AsCode – Terraform Alternative Syntax | Mar 2023
i wonder what advantages this has over using a language-based IaC solution like Pulumi[0]?

[0]: https://github.com/pulumi/pulumi

Wing: A cloud-oriented programming language | Dec 2022
Expand Context ↕
HCL in particular has so many annoying edge-case issues and limitations due to its immaturity that it becomes intractable beyond simple use cases.

Thankfully Pulumi[0] allows me to write Terraform configuration in a language I know without reinventing the wheel. It feels like Pulumi's approach is better in every single way I can imagine. I simply do not see the reason for HCL whatsoever.

[0] https://github.com/pulumi/pulumi
Pyinfra automates infrastructure super fast at scale | Oct 2022
so pulumi[1]?

[1]: https://github.com/pulumi/pulumi

Show HN: Miniboss, versatile local container management with Python | Mar 2022
Expand Context ↕
Check out Pulumi, it's a similar idea of python (or other languages) to generate container orchestration config for Kubernetes or other systems: https://github.com/pulumi/pulumi
Create Terraform files using Python scripts | Jan 2021
Expand Context ↕
> Pulumi literally uses Terraform's custom providers as its dependencies under the hood to make this work.

Right but you can see that the interface is easier as a custom resource though right? The Pulumi docs on making a custom resource are just extending a class. Making a good one I'm sure is fraught with peril but it's so much easier than trying to extend terraform as far as I can see, I'm glad that Pulumi has done this for me.

> Moreover, you're entrusting your entire production stack to an ultra-aggressive, hypergrowth, early stage startup...

Source code is Apache 2.0 and available[0]... I'm not against them trying to profit, but they've created a useful thing that is licensed very permissively (they could have gone with BSL or whatever else)...

[0]: https://github.com/pulumi/pulumi
Use your favorite programming language to provision Infrastructure as Code | Aug 2020
Expand Context ↕
The defining characteristic about Pulumi compared to other tools is that it's not a transpiler, in fact. It's a multi-language runtime written in Go that can host many language plugins (Node.js, Python, .NET, Go, etc), as well as many resource provider plugins (native ones, OpenAPI-based, Terraform-based). So although yes it can use Terraform providers -- great for coverage across many infrastructure providers as well as easy portability if you're coming from Terraform/HCL -- it's not correct to say that it's "just using Terraform" or is a "transpiler".

Pulumi is open source on GitHub if you want to check it out: https://github.com/pulumi/pulumi.
Why are we templating YAML? | Feb 2019
My belief is that we've been slowly building up to using general purpose languages, one small step at a time, throughout the infrastructure as code, DevOps, and SRE journeys this past 10 years. INI files, XML, JSON, and YAML aren't sufficiently expressive -- lacking for loops, conditionals, variable references, and any sort of abstraction -- so, of course, we add templates to it. But as the author (IMHO rightfully) points out, we just end up with a funky, poor approximation of a language.

I think this approach is a byproduct of thinking about infrastructure and configuration -- and the cloud generally -- as an "afterthought," not a core part of an application's infrastructure. Containers, Kubernetes, serverless, and more hosted services all change this, and Chef, Puppet, and others laid the groundwork to think differently about what the future looks like. More developers today than ever before need to think about how to build and configure cloud software.

We started the Pulumi project to solve this very problem, so I'm admittedly biased, and I hope you forgive the plug -- I only mention it here because I think it contributes to the discussion. Our approach is to simply use general purpose languages like TypeScript, Python, and Go, while still having infrastructure as code. An important thing to realize is that infrastructure as code is based on the idea of a goal state. Using a full blown language to generate that goal state generally doesn't threaten the repeatability, determinism, or robustness of the solution, provided you've got an engine handling state management, diffing, resource CRUD, and so on. We've been able to apply this universally across AWS, Azure, GCP, and Kubernetes, often mixing their configuration in the same program.

Again, I'm biased and want to admit that, however if you're sick of YAML, it's definitely worth checking out. We'd love your feedback:

- Project website: https://pulumi.io/

- All open source on GitHub: https://github.com/pulumi/pulumi

- Example of abstractions: https://blog.pulumi.com/the-fastest-path-to-deploying-kubern...

- Example of serverless as event handlers: https://blog.pulumi.com/lambdas-as-lambdas-the-magic-of-simp...

Pulumi may not be the solution for everyone, but I'm fairly optimistic that this is where we're all heading.

Joe