[Pet_Ant]

> 1. A low-level, open-ended language for describing infrastructure; it should have absolutely no facilities for abstraction, should be human-legible and machine-readable (so based on JSON, probably), and should be applicable to everything from configuring physical hosts and switches up to containers.

Sorry, but if it's doesn't have abstraction it's not readable. You get smothered in details. No forest, just trees. People will just create a framework that generates the file like Sass does with CSS.

[6D794163636F756]

I think what is considered low level has to be qualified here. In my opinion I should be able to request virtual cores and memory the same way I do in an os. When in c I can malloc, calloc, or mmap or brk if I'm on a Linux system. If I'm doing concurrent thing in c I have to specifically request a thread then manage it. If I can do these, why can't I have a library where I can make those requests to my cloud provider from my code?

To me, low level would be individually requesting resources as I need them with abstractions that let me ignore physical vs virtual distinctions. To me, this would be fairly readable. C like code requesting then allocating memory and threads just makes sense to me and I don't really care about if they're part of a larger machine. But I also think of low level from my code's perspective not from my infrastructure's perspective.

I'm curious what you think would need to be targeted for something to be both cloud native and low level? I rarely hear people discuss this type of classification.

[twic]

> Sorry, but if it's doesn't have abstraction it's not readable.

This is why i very carefully wrote "legible" instead of "readable".

> You get smothered in details. No forest, just trees. People will just create a framework that generates the file like Sass does with CSS.

That ... is exactly what i was suggesting?!