naserbvqtery

Those things should all still be used with a dsl iac. They're not bringing anything new to the table in the argument of dsl vs general programming language for infrastructure.

Arguably this comment even demonstrates a bit of what I consider one of the biggest problems in the space. It's common for someone who hasn't bought in to dsl based iac tooling to imply dsl based tooling is from a less sophisticated place where modern engineering practices aren't applied, and it's better to grow up and use big-boy tools.

It's almost like they've forgotten the dsl based tooling was in fact built by other application developers with intense subject matter expertise in the space.

> as soon as you need to something higher (usually some sort of looping over a complex data structure and populating fields from those values) it gets real painful

I'd argue this is one such guardrail. Way more than once I've seen infrastructure resources exhausted (frequently cloud provider limits), because a hard line wasn't maintained between infrastructure code and application code. Frequently in the form of "It just makes sense for us to create one %s infrastructure resource for each %s in our application!" followed by a series of midnight conference calls weeks-months later.

Unpopular Opinion:

IaC heavily benefits from not being "Actual Code". While DSL based IaC brings in additional constraints that developers hate dealing with, those constraints very frequently map to constraints in the underlying resources and serve as more of a guardrail than a wall.

I've unfortunately been involved in a number of projects where developers moved from "restrictive" dsl based tooling (puppet, ansible, terraform) to tooling that allowed more free-form code to leak in (chef, cdk, unholy in-house nonsense), and every time I've watched the infrastructure description go from something that could easily be tested and reasoned about to an awful mess nobody wants to touch for fear of breakage.