Hacker News new | ask | show | jobs
by hardwaresofton 2014 days ago
> "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...