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.
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.
> 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.
I think the part that upsets me is he specifically calls out the problem CSS was meant to fix, but then presents the current usage of CSS doesn't fix the problem but instead inverts it. Instead of having to scour code for instances of an attribute you wish to change, you're scouring output for potential negative consequences to a 1px margin shift you added to a style used everywhere.
It seems like this will just amplify mistakes when a lowly dev tries to increase the available RAM of their resource and instead doubles the entire RAM allotment of a resource type for the entire enterprise.
Author of the article here. I totally agree with you on this. There are definitely tradeoffs. However I think the risk of this approach is arguably better than the risk of having every team implementing their own IaC from scratch.
With the CSS example you can have a bunch of very junior developers using Bootstrap and Tailwind with minimal knowledge of CSS and get great results precisely because they don't actually have to change the CSS classes inside of the CSS framework. Junior devs don't make "1px margin shifts" as often because the framework has good margins out of the box. Additionally if needed any "1px margin shifts" that they do make could be enforced by linter or other code policies to happen as a new class, with visibility and limited impact, rather than a change to an existing underlying CSS framework class.
The same could be true for our infrastructure as code if we had similar prepackaged configuration mix-ins. It actually lowers the risk of junior developers making "1px margin shifts" because the IaC framework has sensible config mix-ins out of the box. Most modern IaC just hands the full API surface area to a junior dev, perhaps provides a few examples, and then hopes that they do the right thing with it.
I think modern frameworks like AWS Cloud Development Kit are doing the right thing by implementing higher level methods like `database.connections.allowFrom(service)`, which automatically configures minimal access security groups with the default port of a stack construct, etc. This prevents juniors from making mistakes like opening up every port to every IP address on the internet. However, I think we need the underlying infrastructure as code language to also gain an understanding of mixin methods and traits that can be reused like that, and it needs to be more general purpose.
The "CSS" analogy is a starting point for introducing people to this idea of building reusable resource configuration bundles and resource mutation methods that can be plugged into multiple infrastructure resources and reused, instead of having every IaC stack be its own special hand crafted thing.
This objection reminds me of those to AOP. With great power comes great responsibility. The increased efficiency means you can make the greater investment when it's appropriate and avoid far greater expenditures. Also, tools like Eclipse's XRef view become required.
And in an environment where staff are a cost optimization and not everyone is a 10x coder or engineer, there will be individuals in power who are not as responsible as you would like.
So it's better to have a system where you limit one individual's ability to cause harm rather than amplify it.
In an environment where staff are a cost optimization, tech debt and things like CI/CD are luxuries. Much of it will be half baked or poorly implemented. Automation of unit tests and validation are going to be afterthoughts at best.
Don't get me wrong CSS isn't perfect, but it has done a really good job of scaling through difficult problems as HTML, and browsers, and user expectations have grown over the decades. The tooling and CSS frameworks have gotten really good.
I think HTML + CSS is an example of a declarative system where you can start out not knowing very much about it, just drop in Bootstrap or Tailwind, and start getting great results by using prebuilt CSS classes from someone else.
This is what is missing in most modern infrastructure as code. Sure you can start out with prebuilt IaC templates from someone else, but these templates are basically like getting handed a big chunk of HTML that has inline styles on it. It might render great in the browser and look great, but its hard to read, its hard to understand why it works, and you'll have trouble adding on your changes to it without breaking things.
What I'd like to do is decouple the semantic aspects of infrastructure from the specific configuration aspect, similar to how HTML + CSS lets developers write their semantic markup with semantic CSS class names, and then have a CSS framework provide the exact styles that make it look pretty.
Infrastructure as code needs a similar standard library of semantic configuration mix-ins that you can apply to your infrastructure as layered mutations to produce the final result. There are many tools out there approaching this challenge right now from different ways, and I think the future of infrastructure as code is going to look quite different from what most people are doing today, more like HTML + CSS, or imperative code, than flat YAML and static structures that must list out all their own properties.
I think if you use CSS as a source of lessons learned after the mistakes were implemented and cemented, then yes. If you aim for where CSS was intended, and make decisions which do not compromise that direction, then it's fine goal.
The layering of distinctly-defined concerns contained in separate files which collectively project a merged specification to an IaC tool is a good idea, I think.
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.