Live data from Hacker News

Pulumi – A new open-source cloud development platform

joeduffyblog.com

61–70 of 72 posts

Re: Pulumi – A new open-source cloud development platform

#61

Earlier quoted context omitted.

The main upside is that it's just regular code. This is more natural for some folks, but mainly the advantage is that you can build abstractions. So, you can build a component that's built up from lower-level resources in AWS. For example, directly setting up API Gateway requires a specific setup (and can be error-prone), so there's a Pulumi library for that. My colleague wrote a blog post with more of the technical…

Terraform also lets you create abstractions via modules (admittedly with less flexibility than arbitrary code). I'm still not quite seeing the value proposition here over Terraform.

How do you share and publish terraform modules? Can you pip install a bunch of common configurations, and compose them together with your own app?

It sounds like the value add for this tool is being able to describe your infrastructure as code rather than configuration, with all the benefits of code over configuration (diffs, loops, package managers, variables, etc).

Re: Pulumi – A new open-source cloud development platform

#62
This is beautiful. Looked at the serverless url shortener example. It abstracts over all the configuration garbage and combines all the AWS infrastructure elements as one unified working body.

I'm worried that I might run into a case where it might provision something and I wouldn't know what it did to my AWS account necessarily.

I'll 10/10 give this a go for my next AWS project. Also, no YAML woo!

Re: Pulumi – A new open-source cloud development platform

#63
post #44
post #41

This looks interesting but I really don't like how you're prompted to download and run a shell script from their website without any indication of what it does. I'm all for making it easy to get started, but at least explain what the script does.

Thanks for the feedback! The script will download the latest version of Pulumi, extract it to ~/.pulumi/bin and then try to add that folder to your .bashrc or .bash_profile. You should be able to read the source of the script directly at https://get.pulumi.com/ or even download it yourself, inspect it and then decide if you want to run it or not. You can also follow the manual install instructions which are listed a…

Thanks for responding. :-)

Re: Pulumi – A new open-source cloud development platform

#64

Earlier quoted context omitted.

Terraform also lets you create abstractions via modules (admittedly with less flexibility than arbitrary code). I'm still not quite seeing the value proposition here over Terraform.

How do you share and publish terraform modules? Can you pip install a bunch of common configurations, and compose them together with your own app? It sounds like the value add for this tool is being able to describe your infrastructure as code rather than configuration, with all the benefits of code over configuration (diffs, loops, package managers, variables, etc).

Terraform modules are loaded from local fs, github, or central tf registry - much like pip or npm in spirit.

Re: Pulumi – A new open-source cloud development platform

#65
post #44
post #41

This looks interesting but I really don't like how you're prompted to download and run a shell script from their website without any indication of what it does. I'm all for making it easy to get started, but at least explain what the script does.

Thanks for the feedback! The script will download the latest version of Pulumi, extract it to ~/.pulumi/bin and then try to add that folder to your .bashrc or .bash_profile. You should be able to read the source of the script directly at https://get.pulumi.com/ or even download it yourself, inspect it and then decide if you want to run it or not. You can also follow the manual install instructions which are listed a…

I'd appreciate it if I could install Pulumi via e.g. $ brew install pulumi

That way I'd have a convenient way of keeping it updated to the latest version

Re: Pulumi – A new open-source cloud development platform

#66

Earlier quoted context omitted.

The main upside is that it's just regular code. This is more natural for some folks, but mainly the advantage is that you can build abstractions. So, you can build a component that's built up from lower-level resources in AWS. For example, directly setting up API Gateway requires a specific setup (and can be error-prone), so there's a Pulumi library for that. My colleague wrote a blog post with more of the technical…

Terraform also lets you create abstractions via modules (admittedly with less flexibility than arbitrary code). I'm still not quite seeing the value proposition here over Terraform.

Well, as it was said, it's using a (several) full-fledged programming language(s). If you are a firm believer in the "declarative" ideology you might see this as a drawback. On the other hand I can see from Terraform issues on Github that people sooner or later want something more turing-complete including loops etc. Then you might as well use a real programming language instead of jumping through hoops and trying to emulate stuff like that in your declarative language.

Re: Pulumi – A new open-source cloud development platform

#68
post #27

Earlier quoted context omitted.

Several years ago, my employer created a similar tool with this exact same "feature". What we've found is that while standing up entire stacks in non-prod is kinda cool at first, it's a real drag at scale. We've had to walk back that feature with some hackish workarounds. We've also found that all the API calls necessary to determine what needs to be created can result in us being throttled by Amazon (the dread "Rate…

Could you provide some more detail on what made it a drag? Was it just the Amazon API issues? Cost? Security? Governance? Your experiences here seem like they could be valuable to other folks in the same situation.

Amazon API issues and the amount of time it takes to "discover" complex application stacks in production.

Concrete example: Our framework pulls in remote service dependencies via a link to an ELB in order to set remote HTTP endpoint URLs (yes, we know service discovery is a thing, but that's not where we were when we started). Some projects have 15+ dependencies, and it would take literally hours for it to walk the dependency tree. As a workaround, someone built the capability of passing in those dynamic URL endpoints and then the deployments were revised to build the remote URLs via string interpolation. Deployment time dropped to 10 minutes once we walked away from the concept of deploying stacks from the top down.

2nd concrete example: A developer used an incorrect argument during a deployment and deployed a second full stack of his application rather than replacing a single service. (I understand most other tools have diffs/change sets, but this particular developer isn't the sharpest knife in the drawer...) Rather than fix it immediately, he manually fiddled DNS entries and launch configs to create a mishmash stack. Naturally, he didn't tell anyone, so it took weeks (and lots of EC2 $$$) before we found and fixed it all.

I do see some value in an automated full stack deploy with all dependencies, but it should be the exception and not the rule.

Re: Pulumi – A new open-source cloud development platform

#69

This is beautiful. Looked at the serverless url shortener example. It abstracts over all the configuration garbage and combines all the AWS infrastructure elements as one unified working body. I'm worried that I might run into a case where it might provision something and I wouldn't know what it did to my AWS account necessarily. I'll 10/10 give this a go for my next AWS project. Also, no YAML woo!

(Disclosure: I work at Pulumi.)

The `pulumi update` command first shows you a preview of the exact resources it will create. Once you've deployed, you can view all your resources on the pulumi.com console, so you know exactly what has happened.

Re: Pulumi – A new open-source cloud development platform

#70
post #42

Earlier quoted context omitted.

(I'm a product manager at Pulumi.) > That makes it sound like Pulumi only runs the infrastructure declarations when you run "pulumi update", and that those things don't run when your program runs. That's confusing to me, because your examples (like the thumbnailer) seems to have the program and the declarations in the same file. This is an optional way to do it, by combining the runtime code and infra code. The runti…

Does it understand how to mutate resources in-place with out a downtime? Or is that code/logic something I need to write and track like I do today?

(Disclosure: I work at Pulumi)

Yes, Pulumi does mutate resources in place, if the cloud provider supports it. For most resources, it will create a new one (such as a new ECS task), and wait for it to be ready before deleting the old one.

Post reply on HN