Hacker News Reader

Comment by epgui | Hacker News Reader

First, I have to say this looks awesome. I am in awe at the level of effort I imagine is required to build and maintain something like this.

That being said, I find the rationale a little bit confusing. I rather love IaC, and consider a GUI or no-code/low-code tool to be more of a dead end (not for any fundamental reason, but for more practical reasons) than plain text. I do really appreciate the problems solved by the simulation approach, but to me these two things are orthogonal. I feel like you could have a product that functionally does what your product does, but with a plain text interface. I appreciate that you're really going for something different here, but I am sure I am not the only person who feels this way.

View on HN

I don't think you're alone, and to be honest, I'm as suprised as anyone that it turned out to be better. We built a lot of different implementations on the way here, and all of the initial versions started with code and plain text as the interface. But it's very hard (I think impossible) to change the user experience when you do that, because the data gets locked up in code - there isn't a good way to "see" what the real world is like, or what your proposed changes would do.

But you're not alone in thinking this, and I completely understand why you would. The history of things that look like this in this space is.. not great. :)

> the data gets locked up in code

I'm really not sure that this is a bad thing.

> there isn't a good way to "see" what the real world is like

If the IaC system had the same under-the-hood functionality as System Initiative, what's to stop someone from also building a GUI visualization of the IaC-code?

Think about it this way - how do you update the IaC from multiple places? How do you visualize drift? IaC grows like code grows - it gets factored differently, it gets abstracted, etc. It's easy enough to imagine how you would update a single declaration, but thinking about how to make the "code" reactive will break your brain.

So what we do instead is have a reactive data model, and shift the code part to a reactive graph of functions.

> How do you update the IaC from multiple places?

The same way you update any other code from multiple places. A version control system (eg.: git and github), with CI/CD.

> How do you visualize drift?

Why do you have drift in the first place? Gitops is an obvious solution to drift.

> It’s easy enough to imagine how you would update a single declaration, but thinking about how to make the code reactive will break your brain.

I’m sorry, I don’t follow at all here. I’m not sure what the problem is with IaC. If your IaC is declarative, it’s no more complicated than data.

Reply on news.ycombinator.com