Rethinking Infrastructure as Code from Scratch
nathanpeck.com
Rethinking Infrastructure as Code from Scratch
1–10 of 124 posts
Re: Rethinking Infrastructure as Code from Scratch
#2The author proposes to split structure from parametrisation similarly to how HTML and CSS work.
Re: Rethinking Infrastructure as Code from Scratch
#3What the author appears to miss is that many existing IAC tools permit exactly this.
CDK, CDKTF and Pulumi all use general purpose programming languages, so reusing parameter objects in the way that is described is trivial - indeed it is so close to second nature that I would not even think to write it down. Indeed, it's not uncommon to share functions that make such parameter objects via libraries in the package ecosystem of your choice.
I agree that IaC needs a rethink, but that is more to do with the fact that declarative systems simply cannot model the facts on the ground without being substantially more complex.
Re: Rethinking Infrastructure as Code from Scratch
#4The author seems to considers that the only infrastructure available these days is “the cloud”
Re: Rethinking Infrastructure as Code from Scratch
#5Did that guy just suggest that to make infrastructure-as-code easier to understand we should make it more like CSS?
Re: Rethinking Infrastructure as Code from Scratch
#6> I believe that infrastructure as code languages and tool assisted generators that we currently use are good, and they are taking steps in the right direction, but most of them are trying to patch over underlying complexity in a way that is fundamentally unscalable.
Sure, I can get behind this. Yesterday I was trying to figure out how to give a name to EC2 instances generated by AWS-managed autoscaler group that’s created by a node group resource. Simple, right? should just be able to add a Name = $tag field to the node group somewhere to apply to the generated ec2’s?
well, not quite. What you actually need is a separate autoscaling_group_tag resource.
Well, that resource needs a reference to an autoscaling group arn. but I dont manage an autoscaling group, my node group does, so in the end I have to figure out how to reference it like:
aws_node_group.node_group.resources.0.autoscaling_groups.0.arn
well, not quite, you may need a try block around that, and maybe some lifecycle rules to get around weird race conditions.
so yea. I’m not complaining about HCL or terraform. I find it much better than the alternatives. but lots of times my reaction to stuff like this is “there’s no way it has to be like this.”
Re: Rethinking Infrastructure as Code from Scratch
#7Did that guy just suggest that to make infrastructure-as-code easier to understand we should make it more like CSS ?
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.
Re: Rethinking Infrastructure as Code from Scratch
#8The author seems to considers that the only infrastructure available these days is “the cloud”
I don't see how majority of the stuff wouldn't be applicable for on-prem too?
Re: Rethinking Infrastructure as Code from Scratch
#9What the author appears to miss is that many existing IAC tools permit exactly this. CDK, CDKTF and Pulumi all use general purpose programming languages, so reusing parameter objects in the way that is described is trivial - indeed it is so close to second nature that I would not even think to write it down. Indeed, it's not uncommon to share functions that make such parameter objects via libraries in the package eco…
Adding a "real" programming language makes certain things easier, such as abstraction, but IMO they are too powerful for the task at hand. Do we really want an infrastructure description to be able to execute arbitrary code?
Re: Rethinking Infrastructure as Code from Scratch
#10you lost me at css and typescript