Is a POSIX like interface for cloud infra a bad idea?

Question

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!

bigyabai · Accepted Answer

> 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.

jonahbenton · Answer

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.

alganet · Answer

It depends on a lot of things.How do you plan to manage state?

JojoFatsani · Answer

There&rsquo;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.

Is a POSIX like interface for cloud infra a bad idea?

> 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.

It depends on a lot of things.
How do you plan to manage state?

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.