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

51–55 of 55 posts

Re: Pulumi Insights – AI generated IaC programs

#51

Post by slyall »

nostrebored wrote: post #49
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…

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.

You need a big team to maintain the platform and provide a controlled access to do stuff (PaaS is the buzzword) and then a bunch of above-average devs that are motivated, trained and incentivized to do their own bits of Infra properly.

Possible at FAANG[1] but gets a lot harder as companies get smaller and/or the devs teams are not setup to do that.

[1] I assume the SREs are not the only ones doing the Infra code

Re: Pulumi Insights – AI generated IaC programs

#52

Post by verdverm »

re-thc wrote: post #43
verdverm wrote: post #11

Earlier quoted context omitted.

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…

It's backwards because we used to do it that way and then upgraded to declarative IaC which gave us better reliability and confidence. It's backwards because tools like Pulumi use techniques from before we learned better. It adds more complexity and makes understanding harder. I still don't see how this is a win. The only exception is for developers who don't want to learn the best tools & techniques for IaC, pandering to their preferences over providing better systems. Sure there is a market, but that doesn't make it a good product, especially at scale.

The process of writing, reading, and understanding how the infrastructure comes to be is important. If you have never been on call for a production outage, you won't know how hard it can be to make the correct fix in a stressful situation. Being able to do that is more important than how easy it is for anyone to write the initial version. Take your time writing good IaC during development, make high-stress situations easier.

It's not gated behind a single language, there are multiple tools that provide declarative IaC. You would be surprised at how many folks in the Ops space have not written code beyond simple scripts to glue various tools together. It's something I require for our devops hires, but it is not necessary for all orgs. Most of the time you are writing TF, CF, or Yaml anyway.

It is interesting that Pulumi now supports a Yaml interface, but at that point why use that over TF directly? In the end, Pulumi is just a wrapper around TF. Personally, I use CUE -> tf.json for IaC. It's a much better wrapper with provable correctness.

Re: Pulumi Insights – AI generated IaC programs

#53

Post by diarrhea »

fdgsdfogijq wrote: post #46
gtirloni wrote: post #35

Earlier quoted context omitted.

> exactly to spec And that spec is?

Natural language :)

Reminds me of UML. Instead of laboriously hand-writing all this nasty code, why not use a tool that can autogenerate it for us? After all, all that’s needed is a spec (UML)!

Of course, the spec is the work. LLMs are then just very potent at translating it to be machine-readable.

Re: Pulumi Insights – AI generated IaC programs

#54

Post by re-thc »

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

Earlier quoted context omitted.

> 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 wou…

> This certainly adds pain at times, but overall the business is better off with specialization and experts.

This is where we have architects, microservices and layers of complexity and abstraction.

> and the systems naturally grow large enough that you would have to spend all of your time just keeping up with the changes.

I've seen more cases where it doesn't actually need to be that large - just like you don't need infinite scaling or 1000 microservices and microfrontends. Instead of accepting that it has to grow - think about how it can work together more efficiently. In a lot of situations there's been more downtime due to redundancy, DR and other setups than having a simple instance.

Everyone architects their own part and a build tool / process for each of it... when does it end?

I see these "systems" that mention more as a mess and most people spend 80% of their time to workaround it or just procrastinate at how fragile it is.

Re: Pulumi Insights – AI generated IaC programs

#55

Post by mpweiher »

verdverm wrote: post #52
re-thc wrote: post #43

Earlier quoted context omitted.

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…

It's backwards because we used to do it that way and then upgraded to declarative IaC which gave us better reliability and confidence. It's backwards because tools like Pulumi use techniques from before we learned better. It adds more complexity and makes understanding harder. I still don't see how this is a win. The only exception is for developers who don't want to learn the best tools & techniques for IaC, panderi…

Actually, I think it's not going backwards, but moving in circles, with some changes, hopefully improvements, each time through the loop, so possibly a bit like a corkscrew in 3D. (circles in two dimensions, straight line in third dimension).

Why are we going in circles?

Because there are conflicting requirements and our implicit assumptions prevent us from resolving the conflict.

The conflicting requirements are being able to describe infrastructure in its own terms ("declaratively"), the other is being able to abstract over infrastructure.

If the first requirement is prioritised, we get JSON files, yaml files or specialised IaC DSLs that tend to be limited, partly on purpose, but mostly accidentally, to the point of being crippled. We soon discover the limitations of this approach, which is essentially that for anything a bit more complex we need the abstraction capabilities of a general purpose programming language.

Martin Fowler makes a very similar case for integration here: https://martinfowler.com/articles/cant-buy-integration.html

So the pendulum swings towards general purpose languages with "infrastructure libraries". As far as I can tell, we've had two broad generations of these: the first was libraries to build the infrastructure, the second that we are on now (CDK, Pulumi) output "declarative" descriptions of the infrastructure.

Sounds good, except that there is now a layer of indirection, because essentially all our general purpose languages are actually not general purpose, they are domain specific languages for the domain of algorithms. So what you can express is an algorithm for creating the infrastructure(-description), not the infrastructure(-description) itself.

That doesn't sound like a big deal, but it actually is, not least because the indirection encourages all sorts of shenanigans and messes, including overdosing on indirection.

I think the only way to break out of this back-and-forth (or circle) is to create general purpose languages that can directly express and abstract over things other than algorithms.

Oh, and there's actually a third somewhat conflicting requirement: this description needs to be accessible programmatically (see Kubernetes and friends). If it's true, as I believe, that the other requirements point to a specific linguistic solution, this means that there also must be really great metaprogramming APIs.

Objective-S (http://objective.st) has those capabilities, and recently I've been starting to do some experiments with describing and acting on infrastructure, and the early results have been very promising. Having the concept of URI built into the language (Polymorphic Identifiers) is a good start for directly talking about infrastructure. Storage Combinators also help a lot and the software-architectural concept of a "system" composed of components connected via connectors also seems to map in a fairly straightforward manner.

Post reply on HN