This message was deleted.

sorry to be a bit abstract but: i think, if there are clear use cases where this kind of solution could save an amount of work that is, relative to the effort required, large and compounding ... point-and-click tooling, built on top of useful primitives, is pretty powerful

Agreed that the UI shouldn't be ignored and can be of huge value. But IMO having the underlying power be driven by an API/CLI that can be repurposed for CI/CD pipelines or other GUIs and interaction methods is pretty key to success. With that in mind I'd expect that the UI may come later for a dev platform after the API has started to take form and proven useful for workflows.

Gr8 point on k8 and we had this exact problem of having to come down to using cli to manage our clusters. <advt> we developed a commercial No Code tool to address simple to medium use cases. QMCLOUD.io / As per Gartner these tools are being adopted by platform engineering teams to create blueprints for self service consumption.

@scott molinari if I'm in a new cluster, or a demo, or something, Lens or k9s, 100%. If I'm in a cozy familiar one, always

kubectl

... I'm not sure I've ever paid attention to the "transition" but I'm guessing it's the inertia of knowing

kubectl

better than the GUI tools and needing to do something unfamiliar. Also if I'm copy-pasting bits of a script, terminal is the path of least resistance.

For me it's use case based., I tend to fall back to CLI for those "exceptions to the norm" tasks and use GUIs actually most of the time.

I have frequently asked the opposite question- Are GUI's really necessary? Not to say that they have zero value, but what exactly is the benefit of relying on them for - especially to the exclusion of something that can be used programmatically? A GUI by definition requires a person - a user - to make decisions. This causes errors, which I'd prefer to avoid. It also takes time.. every single time I need to repeat an action. I do use a GUI a first pass to figure something out or understand available options, but beyond that, the goal is to automate all the things. Using kubectl/API calls is the path to automation and being released from having to spend time clicking buttons and drop downs.

I guess to clarify, does using the kube dashboard or the Argo UI to view and occasionally poke, using infrastructure as code to actually provision things, and the CLI for occasional obscure admin tasks make me a UI user?

To @John Starmer comment. Not defending one vs other but the gui tools (atlease what we offer) doesn't break any iac requirements. It does generate code and is accessible to the end user. The value is in Visualization and templatizing. This gives us repeatability, better understanding of what is being deployed or managed (for ops were not everybody is a savvy programmer) etc. In our case the main use case is self service by app developers where they use k8 templates using apis etc and reduces the burden on iac teams. The code as of now is ts and we use pulumi automation api in the backend.

@John Starmer - I'm not questioning the usefulness of a CLI for automation. That's when they are very useful. I'm more concerned about doing work manually. One click in a UI could be a good number of keystrokes in a CLI. If the UI is also done well, the visualizations can help add more context to the workflow making it possibly even intuitive. CLIs are never ever intuitive. 😁

CLI allows you to combine things programmatically. If you find yourself repeating commands over and over again, that's probably a good sign to put them in a script, or better yet build them into the API so you have the option to build both a CLI command and a UI in front of it.