Hacker News new | ask | show | jobs
by twic 1062 days ago
What i think we really need:

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.

2. For each kind of infrastructure, a tool which can apply that language to the infrastructure; one for AWS, one for physical hosts, one for Kubernetes i suppose, etc.

3. Tools and libraries for producing documents in that language from more expressive, concise sources; could be a YAML-to-language compiler, could be a classic Ruby DSL, could be a Python API, could be this guy's CSS idea, could be a GPT prompt, whatever.

Mostly, i want options for the last part to include libraries in sensible programming languages. Then i can just write real code, with full abstractive power, and the possibility of unit tests etc, to define my infrastructure, run it, and feed the output to the applier tool. No more enterprise YAML engineering. No more trying to shoehorn abstraction into Jinja2 templates. Just normal code.

Because the code produces the language, rather than operating on resource directly, writing a new library / DSL / whatever, based on a cool new model which will solve everyone's problems, becomes very easy. You don't have to build a whole IaC tool from scratch.

It also means you have an obvious and simple checkpoint to apply diffing, linting, security checks, etc. Not on the input code, but on the resulting document.

And it means you have one place you can always look to determine the ground truth of what is going on.

3 comments

You just described the role of Terraform. HCL is very JSON like and human readable
fwiw, you can write Terraform in JSON too. Not recommending it, but it's equivalent.
Yea HashiCorp talks about it but also does not recommend it
I've never used Terraform. So HCL is the low-level language i talk about; what does a human write to generate it?
They write HCL/JSON. It’s not by definition low level anything per computer science standards. It’s very high level. It’s declarative.
So not what i described at all then. The whole idea is to have a low-level language you can generate with high-level code written in a real programming language.
IaC isn’t programming. It is more like config files that have some scripting elements like for loops
> 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.

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.

> 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?!

> so based on JSON, probably

How about something better, like EDN? https://github.com/edn-format/edn