[richardjennings]

"Infrastructure As Code" is a misnomer in my opinion. The underlying mechanism is more "Infrastructure as Configuration". Terraform syntax is called HCL "HashiCorp Configuration Language". The "code" aspect of (consuming) Terraform is oriented around providing dynamic configuration capabilities utilising reusable code Modules. As GraphQL has led people to question the applicability of REST type API's in SPA contexts, so I believe IaC will eventually suggest a transition towards single Cloud API endpoints where the entire required state is described; reducing IaC to configuration. Currently the programming or Code aspect is required as a function of API design and the corresponding wiring of components together. Potentially not necessary and not particularly helpful.

[avrionov]

The term makes a lot of sense if you know when and how it was introduced. When the early proponents of "Infrastructure As Code" started to write about it, the infrastructure was defined often time in multiple config files or directly in the UI of tools like load balancers, firewalls, proxies, etc. The big value of the movement for me at least was the proposal to threat the infrastructure definitions and the corresponding scripts as code: - all infrastructure definitions are under source control. - there is well defined process how the changes are made with review and approval process. - the infrastructure can be reproduced and re created for integration environments, load testing, staging etc. - using a common language like Teraform allows better visibility, helps with code reviews, etc.

The cloud providers enabled all that.

To summarize: even if most of "Infrastructure As Code" is implemented via descriptive language and not procedural, it still follows the best software development practices.

[Gravityloss]

Yes, you apply some software development principles: version control, builds, continuous integration, versioning, automation.

The software industry is stupendously large and has invested a lot of person centuries to these concepts and tooling. They have been able to create these tools for themselves because the tools are software. These hard won fruits of labor could be applied to many fields, and are.

Of course some tooling doesn't fit so well directly, there needs to be some adaptation of the concept, and writing of new software and creation of new processes.

[hardwaresofton]

> "Infrastructure As Code" is a misnomer in my opinion. The underlying mechanism is more "Infrastructure as Configuration". Terraform syntax is called HCL "HashiCorp Configuration Language". The "code" aspect of (consuming) Terraform is oriented around providing dynamic configuration capabilities utilising reusable code Modules.

While TF is the most popular interpretation of IaC these days it is definitely not the only way to do it. I have maintained that HCL is the worst part of Terraform -- it's likely that DSL will grow until it very nearly rivals a full grown language, when they could have gone with full blown languages to start (like Pulumi[0]). Terraform does now support native programming language via their CDK support[1]. This meets the "code" requirement.

There is a trade-off of course -- opening up the door to a fully powered programming language means opening the door to infinite complexity, but I think I'd rather have that than have the DSL that has spiky (though constrained) complexity.

> . As GraphQL has led people to question the applicability of REST type API's in SPA contexts, so I believe IaC will eventually suggest a transition towards single Cloud API endpoints where the entire required state is described; reducing IaC to configuration

Agree -- the interface will likely be kubernetes-like.

> Currently the programming or Code aspect is required as a function of API design and the corresponding wiring of components together. Potentially not necessary and not particularly helpful.

On the meta level, it looks like we've run into the ol' "are declarative languages code" (alternatively, "is HTML code?") question.

A free unsolicited hot take on GraphQL: In my opinion GraphQL is just funny looking SQL, which offers every codebase the opportunity to become as complex as the time-tested query execution engines in real production-ready databases. It's almost like how mongo let you pull schema validation and constraint checking from your relational database up to your application language, which as far as I'm concerned is a bad idea most of the time. That said, just like mongo, the productivity brought about by GraphQL is undeniable (whether real or imagined), so I tread lightly and often don't speak ill of it.

[0]: https://www.pulumi.com/docs

[1]: https://www.hashicorp.com/blog/cdk-for-terraform-enabling-py...