Yes Pulumi is nice. Having the power of Typescript types (if you choose Typescript) is amazing.
The thing is I haven't used Terraform extensively so I can't compare.
The main downsides I found are probably IaC downsides in general. Such as scenarios where you need to click-ops to repair because only some of the infra was deployed. I think the clouds need to make their stuff IaC friendly to avoid this though.
My main fear is taking on that dependency on something newer. With Terraform if the company goes bust, the community could take over, and probably it would become an Apache project. Maybe Pulumi would too. It is not good enough for it to be open source. It needs to keep up with the daily changes in the cloud.
Strong agree here - I am still keeping an open mind about TypeScript - using it for frontend / Vercel web apps and while maintaining open-source examples.
I will say it was very nice getting the type hints for infrastructure while developing as well as hints about something being unused, etc.
It overall worked better than I was probably expecting.
Also agree with your points on the pain of IaC - it's terrific when it works but there's always those special "except this resource doesn't follow any of those rules" cases to make things painful and extra complex.
I've also found that IaC can have a chilling effect for folks who haven't ever tried it before - it's a powerful abstraction tool - but at the end of the day you also need some level of understanding around what is happening under the hood - where to debug an error (which level), etc.
I've used Pulumi for professional projects and personal projects, and I think it's fantastic. You can write your code in pretty much any major language (professionally, i use Python, personally I use Go), and you get the same output. Running the Pulumi program itself couldn't be simpler.
My one critique is sort of weird in the sense that Pulumi supports way more than its public documentation says. I hope they up their documentation game in the future, because there are a lot of things that I had to go digging through source code to find out how to implement. But that's really a minor nitpick in the grand scheme of things. Big Pulumi fan here.
Pulumi docs engineer here. Really appreciate that feedback -- what sort of thing did you have to go digging for? We're definitely investing here so I'd love to hear more about what you were looking for and didn't find (or what you discovered along the way that we could've made clearer). Thanks!
It's been a few months, so I can't remember details, but one thing I wanted to use some features was the EventBridge Scheduler and a few other things like that, and I couldn't find anything on the website that referenced those, but I did find the relevant classes defined in the code and was able to get everything working within a few minutes. (Kudos to the comments around the code!)
I agree! Looking at the source code is invaluable. Also if you use Azure, look at the generated ARM templates, for clues on how to set things up where the docs are short on details. It is nice they don't abstract over the ARM templates too much.
I've worked with Terraform extensively, including doing a lot of similar work (Reference Architectures, modules, AWS) over the past several years.
This was my first time using Pulumi, and it was very much a delight. There's clearly been a lot of thought and effort put into the plugins and overall developer experience.
For example, you can have Pulumi handle the Docker image builds for you - as well as the ECR repository logins and pushes. This means that your end users don't need to manually build images, log into ECR and push them - they just run `pulumi up` instead.
My setup extends on this: the pulumi stack creates ECR repo, IAM user+access token, adds credentials and ECR details to GitHub actions secrets, and GitHub actions builds tags and pushes the images to ECR when a release is (automatically) tagged.
For a previous startup a couple of years ago I tried to get our infra onboarded with terraform, hit a bunch of blockers, switched to Pulumi, and have used it for every project big or small since.
Hits a really nice sweet spot for me -- yes, you want your infra definition to be declarative, but being able to write real code in a real language (Typescript in my case) that generates that declarative infra definition is exactly the right level of abstraction imho.
It was my first time working with Pulumi and despite not being sure yet how I truly feel about TypeScript - it was a pleasant experience to be able to use programming constructs I'm already familiar with.
I think that's the real leg up that Pulumi has on Terraform.
With HCL / Terraform - you're supposed to be dealing with configuration, but - we also need loops and maps - so we sort of get a mix between a configuration language and a programming language.
As soon as you need to do something even moderately complex you're in a world of pain (automatically deploying and validating Route 53 records via DNS in AWS, I'm looking at you...).
Comments
Anyone have good experience with Pulumi? The IaC space feels a bit crowded
Yes Pulumi is nice. Having the power of Typescript types (if you choose Typescript) is amazing.
The thing is I haven't used Terraform extensively so I can't compare.
The main downsides I found are probably IaC downsides in general. Such as scenarios where you need to click-ops to repair because only some of the infra was deployed. I think the clouds need to make their stuff IaC friendly to avoid this though.
My main fear is taking on that dependency on something newer. With Terraform if the company goes bust, the community could take over, and probably it would become an Apache project. Maybe Pulumi would too. It is not good enough for it to be open source. It needs to keep up with the daily changes in the cloud.
Strong agree here - I am still keeping an open mind about TypeScript - using it for frontend / Vercel web apps and while maintaining open-source examples.
I will say it was very nice getting the type hints for infrastructure while developing as well as hints about something being unused, etc.
It overall worked better than I was probably expecting.
Also agree with your points on the pain of IaC - it's terrific when it works but there's always those special "except this resource doesn't follow any of those rules" cases to make things painful and extra complex.
I've also found that IaC can have a chilling effect for folks who haven't ever tried it before - it's a powerful abstraction tool - but at the end of the day you also need some level of understanding around what is happening under the hood - where to debug an error (which level), etc.
I've used Pulumi for professional projects and personal projects, and I think it's fantastic. You can write your code in pretty much any major language (professionally, i use Python, personally I use Go), and you get the same output. Running the Pulumi program itself couldn't be simpler.
My one critique is sort of weird in the sense that Pulumi supports way more than its public documentation says. I hope they up their documentation game in the future, because there are a lot of things that I had to go digging through source code to find out how to implement. But that's really a minor nitpick in the grand scheme of things. Big Pulumi fan here.
Pulumi docs engineer here. Really appreciate that feedback -- what sort of thing did you have to go digging for? We're definitely investing here so I'd love to hear more about what you were looking for and didn't find (or what you discovered along the way that we could've made clearer). Thanks!
It's been a few months, so I can't remember details, but one thing I wanted to use some features was the EventBridge Scheduler and a few other things like that, and I couldn't find anything on the website that referenced those, but I did find the relevant classes defined in the code and was able to get everything working within a few minutes. (Kudos to the comments around the code!)
There are more than a few resource types lacking import examples/details in the docs.
Other than that, for most resources I use the docs are pretty good.
Yep, this, exactly.
I agree! Looking at the source code is invaluable. Also if you use Azure, look at the generated ARM templates, for clues on how to set things up where the docs are short on details. It is nice they don't abstract over the ARM templates too much.
I've worked with Terraform extensively, including doing a lot of similar work (Reference Architectures, modules, AWS) over the past several years.
This was my first time using Pulumi, and it was very much a delight. There's clearly been a lot of thought and effort put into the plugins and overall developer experience.
For example, you can have Pulumi handle the Docker image builds for you - as well as the ECR repository logins and pushes. This means that your end users don't need to manually build images, log into ECR and push them - they just run `pulumi up` instead.
My setup extends on this: the pulumi stack creates ECR repo, IAM user+access token, adds credentials and ECR details to GitHub actions secrets, and GitHub actions builds tags and pushes the images to ECR when a release is (automatically) tagged.
Pulumi is (mostly) a bliss!
For a previous startup a couple of years ago I tried to get our infra onboarded with terraform, hit a bunch of blockers, switched to Pulumi, and have used it for every project big or small since.
Hits a really nice sweet spot for me -- yes, you want your infra definition to be declarative, but being able to write real code in a real language (Typescript in my case) that generates that declarative infra definition is exactly the right level of abstraction imho.
This very much gels with my own experience.
It was my first time working with Pulumi and despite not being sure yet how I truly feel about TypeScript - it was a pleasant experience to be able to use programming constructs I'm already familiar with.
I think that's the real leg up that Pulumi has on Terraform.
With HCL / Terraform - you're supposed to be dealing with configuration, but - we also need loops and maps - so we sort of get a mix between a configuration language and a programming language.
As soon as you need to do something even moderately complex you're in a world of pain (automatically deploying and validating Route 53 records via DNS in AWS, I'm looking at you...).