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.
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.
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.
I think the problem is that building any new abstractions is a pretty big lift today, and so innovation is slow moving. Something like this can make that innovation easier, eventually giving way to some simple YAML files.
Unfortunately, it seems like every app eventually has its own pet requirements as it matures, meaning that building new abstractions might be important as part of the UI.
But generally, I agree, tools like this are needed because existing abstractions aren't good enough. I'm just not sure they will ever be good enough when everyone has custom requirements and app-specific architectures.
I'm optimistic, we might have to take a few steps back every now and then, but overall, I think things will improve. Whether that will happen fast enough is anybodies guess...
6 comments
[ 3.7 ms ] story [ 30.7 ms ] threadI 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.
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
Unfortunately, it seems like every app eventually has its own pet requirements as it matures, meaning that building new abstractions might be important as part of the UI.
But generally, I agree, tools like this are needed because existing abstractions aren't good enough. I'm just not sure they will ever be good enough when everyone has custom requirements and app-specific architectures.