Hacker News new | ask | show | jobs
by Cedricgc 2433 days ago
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.

1 comments

Neat, didnt know about CUE, this looks very interesting. Im working on my own wrapper framework (that can also do IaC, but not exclusively), and it supports optional input type specification and validation, to a point. Wish i had known about CUE when I started...

Ended up with a few of the features you mentioned, but not as nicely designed than CUE seems to be, esp. the data injection... Maybe another rewrite is in order... sigh

I highly recommend using CUE for the configuration part. I may not have mentioned this, but CUE is a superset of JSON, You can write the config in CUE then compile the config into a final unified JSON file to be fed into another system. You can separate the orchestration and configuration of a system through an actual data transport system.