Ask HN: Is a POSIX like interface for cloud infra a bad idea? | Hacker News Reader

Ask HN: Is a POSIX like interface for cloud infra a bad idea?

2 pointsAsymi8 comments

As the title says, when humans think about infra, say in a systems design interview, we think high level in terms of components and data flow - not in any particular language (Terraform, CloudFormation) and not in any particular cloud (AWS/GCP/Azure).

I want to be able to declare cloud agnostic infra in some universal language, specify my functional and non functional requirements and push a button to deploy to any cloud.

There would be some intermediate representation of infrastructure and it would then up to us to implement for each cloud. We'd need to maintain a mapping from our language and the clouds in such a way that we can reproduce the infra we need in any cloud from the standard.

We'd need to stay on top of changing cloud APIs and we'd version our language, say a monthly release or something. The focus would be less on how does the user configure X DB, Y message queue, and Z compute - and more the user tells us that X, Y, Z should satisfy some NFRs and be connected in some way. Then we'd just create the infra for them.

I know this sounds a lot like Terraform, but I use that on the daily and have seen first hand how hard it is to go from one cloud to another. I'm aware cloud providers don't have an incentive to be interoperable and did some brief research on the topic. Seems like this has been tried before and hasn't really taken off - why is that? Just too hard? Cloud providers won't let you?

Is it a tarpit idea? Please let me know!

The answer is probably a high level LLM supported agentic spec driven development workflow. A low level version of this can kind of be accomplished interactively with the cloud specific MCPs- noting that each major infra component has its own MCP exposing the complete API surface of that component. The prompts that could drive component interrogation (to get current state, which would no longer live in a TF state file in S3) and then would drive updates and changes would themselves need to be generated, hence the higher level agentic function. Driving the agentic prompt gen would be a spec driven workflow. You would maintain the natural language spec and would conversationally arrive at spec updates that would lead to proposed infra changes for approval.

Ah that sounds very cool, so instead of having some deterministic mapping, you could just specify the requirements and have a test, the agent would iterate until it passes all tests - so you wouldn't actually need to maintain a codebase to translate from your language spec to cloud providers APIs. This is a cool way of thinking about it and I guess I'm still stuck in 2015! Going to give this a try and see how far it can go.

> I want to be able to declare cloud agnostic infra in some universal language, specify my functional and non functional requirements and push a button to deploy to any cloud.

Basically what NixOS is in my experience, where "cloud" is "NixOS machine" in this instance.

Oh cool, this is completely new to me, going to check it out.

There’s probably a Kubernetes operator pattern you could use for this. But really Terraform is hard to beat as the best abstraction for infra IMO.

It depends on a lot of things.

How do you plan to manage state?

Good question, I like the idea JohnaBenton suggested of farming off the mappings to an agent. As I understand it, you'd have a meta agent that consumes the spec and then an agent for each cloud that translates the spec.

A while back I thought that infra can be represented as a graph (a node is a think and a link is a relationship between things) so was leaning to having some kind of internal representation in a graph DB instead of a state file - but in the agentic age, I actually don't know if this even makes sense.

I see.

Why not have the LLM generate the whole thing? I mean, just prompt it to manage the cloud for you. Use some markdowns to keep the things that work, discard the things that don't, and keep doing trial and error until it works for your scenario.

You just need to find a reusable unit for those markdowns. Something simple and easy that can be composed and would allow an easier time doing the trial and error stuff.

Reply on news.ycombinator.com