Hacker News Reader

Comment by c7DJTLrn | Hacker News Reader

It looks cool, but I would be hesitant to leave IaC behind. DevOps/sysadmin kind of people are infamous for (generally) not liking GUIs for a reason. We like being able to grep through a repo, revert to older versions of the code, and deploy new infra all through the CLI.

It might be adopted by people who already do ClickOps or aren't comfortable with the CLI, but I'm not sure about the rest of us. Looking forward to seeing how it progresses.

View on HN

Skepticism here is warranted - the history of things that look like this in our space isn't fantastic. We've put a lot of engineering into trying to create something that is a power tool, and flexible enough to solve hard real world problems. It's early, and we've got lots of work to do, but that's the goal.

I heard in a Podcast that they are inspired by game development workflow (e.g. Unity) where multiple teams can work together in a unified way. This reduces "niche" power like CLI commands that only some of sysadmins can wield.

Personally, as an infrastructure engineer, I still prefer CLI and everything as (text) code. But I'm open to change if this "second wave" could take off.

As someone who works on games professionally, the first thing people do is turn on the text support for unity assets. Unreal still uses binary assets and it's a giant pain in the ass.

The problem isn't that everything should be text, it's that there are no tools out there that work with other content types. Semantic diff tools would be incredible honestly, and text is a poor representation of code. It's just the best we have right now

I tend to romanticize CLI as a universal and think of GUIs as niche, so it struck me odd to see CLIs referred to that way. That's not a character judgement. I'm actually curious what you mean by niche. Would you mind elaborating?

Infrastructure components should still be written in code but composing multiple components (network, infra, database) is often a Byzantine maze of different tooling/language choices (terraform/pulumi/crossplane) and multiple pull requests.

If you shift to an application developers perspective, and zoom out a level most medium/large org still require interaction with multiple teams to spin up an application. Testing and deploying this stack end to end is expensive and time consuming.

I’m not sure what the optimal solution looks like, but certainly open to tools that force us to think more about building interfaces around infra components and wire it together without navigating PRs in a dozen different repos. PR should be the process to create a new version of a component, but not an API for users requesting an instance of that component.

Reply on news.ycombinator.com