Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pulumi Insights – AI generated IaC programs

pulumi.com

Post reply on HN
Print view View original

41–50 of 55 posts

Re: Pulumi Insights – AI generated IaC programs

#41

Post by re-thc »

verdverm wrote: post #27
nostrebored wrote: post #17

Earlier quoted context omitted.

I think the fact that there are “infrastructure people” vending infra for devs is usually evidence of a mistake. If you have platform engineers, sure, that makes a ton of sense. But adding friction to the developer workflow of waiting for someone else to do something that’s an API call away is strange

It's very valuable to have someone on your team thinking about infra all the time. We know that we are constantly pulled in many directions in our industry, and often we take shortcuts to get the work out the door. Infra is not a place you typically want to take shortcuts. Burdening devs with the infra | ops responsibilities is a sure way to security incidents and inflated costs. It does provide a good market for con…

> If we look at this job separation in a different analogy, why do we typically separate FE & BE development? b/c people can only be expected to be proficient in so much of the stack? And you typically want someone around who is proficient for each part of the stack?

It's just been a convenient way to divide up the work? When FE & BE don't work together and aren't aware of each other it's just another mess. And then people invented Backend For Frontend to deal with it or GraphQL. We're just adding more layers and abstractions and complexities on top.

It's valuable to have someone to be dedicated to infrastructure. It's even more valuable for everyone to be aware of the whole ecosystem. No 1 lives in a silo.

Re: Pulumi Insights – AI generated IaC programs

#42

Post by trufas »

verdverm wrote: post #15
smt88 wrote: post #4

Earlier quoted context omitted.

Why would you need LLMs for a boilerplate web application?

There is a "need" vs "want" aspect here, but often the boilerplates that we reach for become out of date. In theory, an LLM producing these could remain up to date without maintenance, key phrase "in theory"

There's no guarantee the boilerplate an LLM spits out will be up to date. It'll almost definitely have some outdated code in it's dataset that it can reference.

Re: Pulumi Insights – AI generated IaC programs

#43

Post by re-thc »

verdverm wrote: post #11
cedws wrote: post #7

Sorry to be offtopic, but I've been using Pulumi at work for the past 6 months and I'm really not impressed. It's basically just Terraform but worse, with a million ways to declare your infrastructure instead of just one. Infrastructure people tend not to write the best code and from my observation the extra freedom of an imperative language just makes stuff even more complex and harder to maintain. It's also much ha…

Agreement, I do not understand this backwards movement in the DevOps world. My hypothesis is that they are catering to a different group, i.e. enabling developers to do Ops, who don't want to learn TF and want to use their preferred language. DevOps first practitioners are in short supply, so it makes sense there is a market for this.

Why is it backwards? Is making it more accessible and inclusive backwards? So these "DevOps practitioners" who are so different according to you never used Python or any programming language?

We should enable everyone to at least aware of Ops and be able to contribute. Why does it need to be gated behind a special language i.e. HCL?

A lot of times things go rogue exactly because developers don't understand and claim to not have a need to understand because it's not their job. Ultimately the code runs on the infrastructure provisioned just like how we live on Earth altogether.

Just like moving to recycling and clean energy the only way is to go at it together and not create more divide.

Re: Pulumi Insights – AI generated IaC programs

#44

Post by re-thc »

verdverm wrote: post #24
dmattia wrote: post #21

Earlier quoted context omitted.

You've used Pulumi extensively and don't see a single benefit? Here's setting up Guardduty in AWS in multiple regions using a terraform module: https://github.com/gruntwork-io/terraform-aws-security/blob/... In pulumi, it would be: ``` import * as pulumi from "@pulumi/pulumi"; import * as aws from "@pulumi/aws"; [ "us-east-1", "us-east-2", "us-west-1", "us-west-2", "ap-south-1", "ap-northeast-2", "ap-southeast-1", "a…

If I use Python for my Pulumi, how could I reuse the work of a peer who uses JS for Pulumi? Do we need to have multiple "mirrors" of our internal infra modules? Or do we need multiple language runtimes in our deployment runner in CI? With TF, there is one language and one binary

> If I use Python for my Pulumi, how could I reuse the work of a peer who uses JS for Pulumi?

Standardize on the language(s). It's important. Pick 1 for Pulumi and standardize on it. Even better pick 1 or 2 for the whole company and standardize on it. In a large company...

> Or do we need multiple language runtimes in our deployment runner in CI?

Already does happen.

But back to the origin question: you can create Pulumi packages that can generate usage in different languages as required.

Re: Pulumi Insights – AI generated IaC programs

#45

Post by rcarr »

I had a really bad experience with Pulumi in February/March that probably cost me around 4 weeks of lost dev time, possibly more. Context: Not a DevOps guy, created a serverless site using Typescript, created the infrastructure for it on AWS console and then decided to try and replicate it using Pulumi to get some IaC skills.

Issues:

- The majority of the documentation/examples assume you are going to be writing all your code in one big long index.js file rather than the micro stacks approach. No idea why this is considering no-one organises their code this way in any other part of a coding project so don't know why micro stack approach would not be the default approach.

- Major issues getting it to work with typescript/ts-node/tsx correctly. Could only manage to do this if I used a Pulumi Automation Runtime program rather than a Pulumi Automation Local program which was super awkward as it meant I lost access to using the CLI.

- No way of testing any serverless function that called another serverless function. Would have to use something like LocalStack if you wanted to do this (and that seemed like a nightmare) or use a npm module that didn't seem like a safe long term bet. Not entirely pulumi's fault but if you want to do this it can be done with SST or with Amazon SAM.

In the end I ended up giving up on Pulumi and will be rewriting the entire infrastructure code using SST. If I had an app that wasn't serverless I'd consider using it again but definitely wouldn't give it another shot for a serverless app until it either has similar testing functionality for serverless functions as SST or if there's an official way of interfacing with the SST framework. I'd also probably hold out until monorepo and Typescript support was better.

My frustration levels were elevated going into the month as I built the site using a new framework that went from 1.0 to 2.0 mid development and had to learn the idiosyncrasies of that. However the month from hell with Pulumi was enough to send me over the edge and I'm now taking a few weeks off from coding to get my patience back again.

Oh and I've no idea what this AI thing is like but when I tried to get ChatGPT to answer questions on Pulumi it was useless. It would flat out lie and make up classes and functions that didn't exist.

Re: Pulumi Insights – AI generated IaC programs

#47

Post by verdverm »

re-thc wrote: post #41
verdverm wrote: post #27

Earlier quoted context omitted.

It's very valuable to have someone on your team thinking about infra all the time. We know that we are constantly pulled in many directions in our industry, and often we take shortcuts to get the work out the door. Infra is not a place you typically want to take shortcuts. Burdening devs with the infra | ops responsibilities is a sure way to security incidents and inflated costs. It does provide a good market for con…

> If we look at this job separation in a different analogy, why do we typically separate FE & BE development? b/c people can only be expected to be proficient in so much of the stack? And you typically want someone around who is proficient for each part of the stack? It's just been a convenient way to divide up the work? When FE & BE don't work together and aren't aware of each other it's just another mess. And then…

Truth, I've built a lot of automation for a CI / ops system. The devs have not taken the time to learn it, because business needs them to deliver value to the user. This certainly adds pain at times, but overall the business is better off with specialization and experts.

In an ideal world, it would be great for everyone to be aware, but people have limited time and the systems naturally grow large enough that you would have to spend all of your time just keeping up with the changes.

Re: Pulumi Insights – AI generated IaC programs

#48

Post by verdverm »

trufas wrote: post #42
verdverm wrote: post #15

Earlier quoted context omitted.

There is a "need" vs "want" aspect here, but often the boilerplates that we reach for become out of date. In theory, an LLM producing these could remain up to date without maintenance, key phrase "in theory"

There's no guarantee the boilerplate an LLM spits out will be up to date. It'll almost definitely have some outdated code in it's dataset that it can reference.

yes, a basic LLM is susceptible to this. The other major issue is that they will generate different output, even with the same input.

There is work going into giving the LLMs access to external data & systems. This is my basis for saying they will be able to stay up to date.

I have a very different approach I'm working on: https://docs.hofstadter.io/getting-started/creators (human-made blueprints that can be started from and later updated to bring in the upstream changes)

Re: Pulumi Insights – AI generated IaC programs

#49

Post by nostrebored »

verdverm wrote: post #27
nostrebored wrote: post #17

Earlier quoted context omitted.

I think the fact that there are “infrastructure people” vending infra for devs is usually evidence of a mistake. If you have platform engineers, sure, that makes a ton of sense. But adding friction to the developer workflow of waiting for someone else to do something that’s an API call away is strange

It's very valuable to have someone on your team thinking about infra all the time. We know that we are constantly pulled in many directions in our industry, and often we take shortcuts to get the work out the door. Infra is not a place you typically want to take shortcuts. Burdening devs with the infra | ops responsibilities is a sure way to security incidents and inflated costs. It does provide a good market for con…

Amazon seems to do it fine, as have many other places I’ve worked.

The truth is that infrastructure is not that complex when you have someone giving you building blocks and setting up guardrails. Having someone give you the pipelines and setting the boundaries is great. Choosing the pieces to get the product over the line is not that hard in a world where cloud is the norm.

Re: Pulumi Insights – AI generated IaC programs

#50

Post by nostrebored »

c7DJTLrn wrote: post #22
nostrebored wrote: post #17

Earlier quoted context omitted.

I think the fact that there are “infrastructure people” vending infra for devs is usually evidence of a mistake. If you have platform engineers, sure, that makes a ton of sense. But adding friction to the developer workflow of waiting for someone else to do something that’s an API call away is strange

I see what you're saying but I also don't. Developers can't be expected to maintain the infrastructure too, there's an immense amount of work involved to keep it reliable and secure.

Sure, there is. Let your cloud provider do that work. They’ll do it better and it lets you keep a platform team focused on where they add value.
Post reply on HN