Infrastructure as Code, Not Infrastructure as Files

I consider this new tool being promoted here (Adapt) to be in a similar space to Pulumi (https://www.pulumi.com) which allows for using full featured imperative programming languages for defining infrastructure. The key idea is that the writer can do anything in the code (unless sandboxed) but must return a data structure that will then be passed to the a system to actually orchestrate the cloud provider APIs for you. I can see some potential of using react features for IaC, like leveraging lifecyle hooks for state changes and the React Context API for threading state deep into subtrees of the data structure.

I was attracted to this style of IaC for awhile as I had my own frustrations with the current 'YAML Engineering' that we have to do. After looking at the space I am bullish on CUE (https://cuelang.org/docs/about/) for IaC. There are some points that these imperative-declarative systems still do not address that are critical for IaC:

- Data validation and constraints. A config should be a structure of fields and what types they should be. If needed they can be further specified into concrete types. In CUE, types are values and multiple field definitions are unified to their most concrete type. For example, if `a: >5` and `a: <10` and `a:7` would unify to`a:7`. `a:11` would not be a valid unfication.

- Deep nested configuration: Configuration are a tree structure that can have values that need to be overridden deep in the structure. Imperative languages rely on functions for abstraction, but that is fragile as you need to basically expose every field as a function parameter at some point. CUE does not have functions but instead relies and templates, constraints, and easy overriding of values deep in the tree to achieve a similar effect.

- External data injection: Most configuration systems need to be able to inject data into the environment to be evaluated at runtime. This usually requires wrapping the tool in another tool in a fragile way. CUE has a scripting layer to allow injecting data into the execution environment without wrapping.

Interesting approach. In general, I always prefer 'Infrastructure as files' as the article calls it. I think if that's not possible in any specific scenario then we just didn't create the right abstractions yet. In the devops space I think we're still a far way off, so tools like the one mentioned in the article can help us get there. But I would not think they should be the ' user interface', so to say. That should be a data structure of some sort, ideally as small as possible, typed and validatable.