> The point here is that while Terraform and similiar technologies have existed for the past decade, providing Ops and Infrastructure teams with the tools they need to cleanly document their infrastructure, application development teams have had access to no such tools in this time.

...Don't they have access to the same tools, though? And if they don't, it sounds more like an internal policy issue or operational inefficiency of whatever org they're in? Terraform is Terraform for developers.

Besides, I believe the promoted approach is fundamentally misguided.

Application code has no business getting involved in the infrastructure it's running on. They layers of abstraction should be separated.

It's fine if your team manages their own Dockerfiles, k8s schemas, helm charts, terraform/CF templates or whathaveyou. Cohost them in the same git repo even, if you must. Use all the platform-specific APIs and integrations you want.

The application itself should be competetely agnostic to all of that, though, and has no business interacting with any of those APIs. You use common interfaces like environment variables, filesystem, and CLI flags to communicate between upper and lower layers. You do not have your services go and read k8s secrets over API, interact with the container runtime, or make direct API calls to ECS[0], for example. You keep those layers abstracted away from application code. That has nothing to do with the "who".

On a language level, there are _very_ good reasons to prefer a declarative DSL over any turing-complete general-purpose language. Not saying you should use HCL specifically but scripting your infrastructure provisioning in JS doesn't seem like a step forward compared to ye olde bash scripts...

[0]: I'm sure you have a valid counter-example. The point still stands in general.