Maybe I'm a complete beginner and don't know what I don't know, but having seen Terraform, I recognize immediately the value of simplifying deployment through configuration or 'infrastructure as code'.

I don't know a fucking thing about it, or how to actually do it, and don't even have a need for it because I don't program at that scale, but it looks really fun to work with.

I'm not gonna lie, the initial steps - be it Terraform or similar approaches - are hard.

A lot of planning, tinkering, going back to the drawing board, tinkering, fucking around... Lots of interdisciplinary knowledge. Looooooooooooots of wheels needed to form a nice spinning cog.

But when it finally starts turning, it's a true blessing.

Cause a lot of the otherwise hard, manual labor will be automated.

If you ever had to set up a lot of VMs manually or only partially automated, e.g. by Proxmox rest interface... I think you understand what I mean.

Lots of triple checking, cause repeating the same task over and over with only small changes in the workflow is a disaster waiting to happen.

E.g. I once forgot to add the /24 to a network IP address in 30 machines.

Brain just KOed out. It was... Interesting to find out. Luckily I prepped a lot of shenanigans like git backup + diffing automated around it, otherwise these missing 3 chars would probably cost me my sanity. Especially when you've done 12 hours plus straight nothing but the same workflow over and over.

:-( the good old days.

@IntrusionCM From what you said, it kinda surprises me that someone hasn't done for terraform what docker did for container support.

Hell I'm really surprised someone hasn't built a clean UI frontend for terraform.

That sounds like a fun project. I mean I'm obviously i'm probably in way over, and slightly insane considering the definition of 'fun' here, but still, it sounds like it would be fun to build.

@Wisecrack

I guess people dealing with infrastructure hardly ever use a GUI. (at least I don't).

I'd think it's natural given you work constantly with boxes that don't even have a graphical interface to begin with.

@CoreFusionX It's be interesting to write gui-as-api.

Like something you plug-and-play from a usb. Think of it as an OS but for your data.

And what you do is you plug in a physical terminal unit with this thing loaded, or remote into a shell, it detects a standarized configuration file that provides an api to your data, and in exchange the system, based on config options, provides a sort of api to an adaptive ui system.

the system shell takes the config that describes your data and availability, and provides an adaptive interface to it. Sort of like a plug-n-play dashboard system. The system in exchange spawns a user interface that provides sensible defaults for representing data and input to it (if thats required), based on the types of data.

I don't know, maybe this is a common thing. I just see a lot of rehashes of CRUD where its "export csv, import to dashboard" and I'm kinda surprised this idea hasn't been extended significantly.

like if the data is what matters, and the context is known (financial, health, cloud, server rack without an interface, etc), it just surprises me that data-to-xyz-ui-mapping conventions haven't been standardized into a plug-n-play type system so we can fire and forget, and decide on any edge cases or specialized configurations we need instead of redesigning and re-implementing the same CRUD interfaces over and fucking over.

Design thinking needs to move on from that to "how do I massage my data pipeline api in such a way that I end up with xyz interface?"

And then turning those configuration practices, into conventions or reusable modules themselves.

I don't want to reinvent the wheel. I want to build machines that take specifications for wheels, and decide, based on sensible defaults (built around best practice), what those specifications (data) will be implemented as or look like.