[cptskippy]

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.

[NathanKP]

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.

[erikerikson]

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.

[cptskippy]

> With great power comes great responsibility.

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.

[erikerikson]

Automated validation has always seemed to catch that sort of risk just fine.

[cptskippy]

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.