
Infrastructure as Code, Not Infrastructure as Files - mv1
https://hackernoon.com/react-for-infrastructure-n84n2dw7
======
Cedricgc
I consider this new tool being promoted here (Adapt) to be in a similar space
to Pulumi ([https://www.pulumi.com](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/](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.

~~~
_frkl
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_

~~~
Cedricgc
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.

------
_frkl
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.

~~~
mv1
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.

~~~
_frkl
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...

