We are building a CLI first PaaS without a web frontend | Hacker News Reader

We are building a CLI first PaaS without a web frontend

crufter.com

153 pointsfriendly_chap101 comments

A CLI offers horrible discoverability compared to a UI where you can properly model UX. You can sorta approximate it with TUIs, but then you're basically building a simplified UI anyways.

I say this as someone that's a heavy CLI user, but I simply don't care to remember CLI options for anything I don't use a ton of times every day (like git).

Just the AWS Lambda page in the AWS Console would take a whole bunch of CLI requests to even gather the basic information that's shown there, and that's ignoring you won't get the metrics visualization that'll tell you that your function every now and then has some outlier durations.

My point being: UIs (GUIs) are not just for non-power users—they are indeed for power users as well.

There are plenty of GUIs less discoverable than a documented CLI with completion.

Sure, but that doesn’t change the point I don’t think. By and large, regardless of the existence of what you’re saying, GUIs lead to greater discoverability.

They simply don't. Good GUIs lead to better discovery.

Pardon my potential ignorance here, but it seems to me a valid argument to simply say "if the GUI lets you search, that alone will probably make it more 'discoverable' than a CLI".

Doesn't cli-tool --help cover discoverability in a more complete and formal way than a gui?

Your AWS Lambda example seems to be about observability, which I agree is better suited to a gui.

I don't think that's true. Three ways that are de-facto standarized for CLIs for discoverability (where UI has almost no de-facto standards like this):

- `man $program` - Usually shows EVERYTHING you can do with the tool

- `$program --help` - shows a brief help with flags, parameters and commands

- `$program $cmd --help` specific help for that command

Most CLI tools implement these and most of everyone who is using a terminal daily knows about those three ways.

In the GUI world, you sometimes have a "Help" link in the menu bar, that either opens a little widget or a web page. Nothing like man pages for GUIs.

It's frustrating, but people often seem to say "discoverable" when they mean "doesn't need a manual" or "intuitive". So CLIs that don't conform to standard patterns, or whose subcommands/options don't make intuitive sense would be "non-discoverable".

But also, well-written manuals and usage/help screens are becoming increasingly rare these days. Technical writing is time consuming and people choose not to do it.

Building GUIs is time consuming as well. I just don't think it is as common to find good technical writers instead of ui designers?

I'd say its less common for a project to have budget for a technical writer. I think there are plenty of people who have stellar writing ability, it's just nobody is willing to pay for it.

I remember back when I ran Ironport appliances it came with a giant manual - maybe 1000 pages. It was very well written, had CLI excerpts, explained theory, etc. It was amazing.

Companies see things like admins, technical writers, configuration management as excess. Technology today has reduced the need for these specialist-but-not-core-to-the-business roles. So the work is increasingly piled on the specialist in other fields rather than being a specialist position of its own.

"I'm not paid to write manuals" is a common refrain in places I've been. The developer wants to write the code, maybe write the spec and design document. But they have no interest in writing the manual because "it's not my job." Only, today, it is their job because their employers (contrary to last century) don't employ writers on staff and contracting for fast changing documentation to keep up with fast changing systems isn't worth the effort. So it's up to the dev.

Same with many other tasks. There have been some really good articles about the impact on professions like professors, teachers, doctors and others as their workload has increased. Why? Because technology has reduced each individual task to something small, but cumulatively it's drowning them (and us). Something has to give. The shifted work makes sense until you look at the aggregate impact.

In the case of doctors, they have little they can avoid doing so they just drown in work. Teachers are made to work 12-16 hour days during the school year. But we, the programmers, get to skimp on these things (and hurt our users) because it hasn't yet hurt our bottom-line or cost any lives (safety critical systems still do a better job here out of necessity).

I wonder why we already don't have automated GUIs generated for command line utilities using their man pages. It should be trivial, isn't it?

Not sure it'd be trivial unless the documentation is really good. I have, however, seen TCL used to good effect of GUIfying a CLI, and providing a scriptable interface so that you can access features that don't translate well to the GUI or (for whatever reason) haven't been made directly accessible in the GUI.

We have had automated GUIs generated for command line utilities since PowerShell 2:

    PS C:\> show-command get-childitem

will popup a GUI form for all the options get-childitem takes. It's basically useless because it's a dump of all available parameters. At least they're in alphabetical order, but there's no hint which ones you might want or not want.

Apple did something like this with A/UX back in the day (their variant of Unix which apple sold for its 68k machines). https://en.wikipedia.org/wiki/A/UX The tool that did this was called Commando; I'm not sure if it was hand-crafted, or automatic.

A huge part of the problem is that `man` pages really are only softly standardized, and just, commandline options in general are just softly standardized. They don't all obey the same rules for spaces, capitalization, usage of dashes, etc - they're close, but it's far from consistent.

What we ought to have done at some point, would have been to rebuild the whole suite of commandline utils - to make them all do an ironclad standard, and probably even make them all spit out a totally normalized data format like JSON, man pages included, so that external tools could be built around them way easier without everyone having to write their own parser (or - having to write a generalized parser with tons of 'special-case exemptions' for all the CLI tools that break the rules).

There have been several attempts, but nobody's been willing to do the big "rip off the bandaid" and take the pain of breaking legacy scripts.

Good points, especially about the lack of documentation. Regardless of the type of interface, people need references to go with them.

Discoverability can mean more than discovering features of the app too. To me, I think more about discovering information contained within it, seeing things I wouldn't have noticed in a command line experience. In a complex system like server automation, there's actually a lot of potential value in GUIs making it easier to see correlations between things or notice problems or discrepancies before they become bigger issues.

I've been a command line-first user since the 90's, but I would hesitate to recommend this over other solutions specifically because of the lack of GUI.

Tab autocompletion comes close. And, in keeping with that analogy, is often one of the most annoying parts to write.

Don't forget `-h` "chastise me for not using --help, and don't show the help".

and `-h` print "usage: $program [TBhrRtzFwbvjEBUQ]"

This is assuming all the commands are in one binary, and you know what the binary is (compare 'yum install' and 'yum search' with 'apt-get install' vs 'apt-cache search').

> Most CLI tools implement these

Most? You can see there's a big competing pattern of having multiple binaries with the same prefix like ssh ssh-agent ssh-keygen, dbus-FOO dpkg-FOO apt-FOO snmpFOO ldapFOO.

And there are plenty which don't have this "clearly delineated sub-command" like git has.

> where [GUI] has almost no de-facto standards like this

The massive main de-facto standard a GUI has is showing you important things up front and hiding irrelevant and uncommon things away. With a CLI you see nothing until you --help then you see everything. There's no indication of what's a common path through the tool.

openssl sha --help shows "-non-fips-allow" above "-sha1".

It's not showing options in alphabetical order. Am I to infer that "-sigopt nm:v" is more common, more used, more important, than "use SHA1" because it's higher up in the list? If not, why is it higher up in the list?

Hamburger menu? Right-click on a thing to show you a context menu of things you can do with a thing? A central content area with "tabbed sections" along the top (real tabs or links like a menu bar)? Mouse hover-and-pause tooltip? "select an item and press F1 for help"? Have a username link or avatar picture behind which your user-specific options are? Are these not large and common "de-facto standards" in GUIs?

> You can see there's a big competing pattern of having multiple binaries with the same prefix

One could create an entire ecology of tools that operates as a sort of compromise: Have a family of separate programs named with a common prefix (e.g., foo-), and a dispatch program (foo) that, when run like

  foo bar options

dispatches to foo-bar with the options, and when run like

  foo [-h|--help]

prints a help message and then lists every foo- program on the PATH, incorporating the whatis output where available. (That last bit requires man pages to work, but you can't very well tell people to read a manual that doesn't exist.)

I have used this strategy at work with considerable success.

I believe Cargo (of the Rust ecosystem) works this way. One benefit is that it can be extended by the community (for example, cargo-update).

Hah, `man aws` prints `No manual entry for aws`. You can of course dig around the help pages for each individual subcommand, but it doesn't give a very good idea about how the resources stitch together. More importantly, you miss out on the wizard-like behavior for spinning up new resources without needing to provide a reference to each upstream resource (the GUI can create these upstream resources for you or let you bring your own depending on how you navigate the creation wizard). I'm sure this is all possible with a sufficiently well-designed CLI (`eksctl` does this for EKS), but no such CLI exists for AWS holistically and these are pretty rare for any kind of application.

Also, personally I really dislike man pages--paging through tons and tons of text that has nothing to do with my use case to find the one or two bits that are actually relevant is not really my idea of a good time. They are the most flat-footed solution to the discoverability problem, but they leave a lot to be desired.

/<search term> will make your life so much easier. Manually paging through man pages sounds awful.

To be clear, my comment was about using `/<search term>`, not manually paging. It's still a very unpleasant experience. If you're interested in a particular concept, but you're not sure what your program calls it, good luck. Even if you're looking for a particular flag (e.g., `-c`) you can have hundreds of search results to parse through depending on the size of the man page. I personally don't enjoy this experience.

I'm a big CLI user, but my primary gripe with these sorts of interfaces vs a GUI is when they have a huge number of nested sub commands. I often find myself searching through the tree of possibilities running --help on every single level just to do something simple. Especially if what I'm trying to do may exist in disparate sub commands. With a web interface there'd likely be some kind of nested menu or dropdowns that offer more of a sense of the overall arrangement at a glance.

I'm always happy to have access to the CLI to be able to script things, but if it's the only interface to a service with many features it can be awfully cumbersome.

Sometimes with these deeply nested do-it-all CLIs I feel like I'm playing a text adventure trying to navigate a maze, constantly typing /look and /examine. Often these tools have so many sub commands that a man page is not helpful if it exists at all.

  > cloud-tool --help
  ...
  > cloud-tool instances --help
  ...
  > cloud-tool instances attach-storage --help
  ...
  > cloud-tool instances attach-storage disk --help
  ...
  > cloud-tool storage --help
  ... 
  > cloud-tool disks --help
  ...
  > cloud-tool disks provision --help
  ...
  > cloud-tool disks provision --size 200gb --name new-disk
  Your session has expired please log in again.
  > cloud-tool --help
  ...
  > cloud-tool auth --help
  ...
  > cloud-tool auth login
  ...
  > cloud-tool storage provision --size 200gb --name new-disk
  ...
  > cloud-tool instances attach-storage --help
  ...
  > cloud-tool instances attach-storage disk --name new-disk

The best CLI manpage I've ever seen address this was linux's `ip` command (of the iproute2 package/tool suite).

It starts with a BNF grammar of the various subcommands and options.

Plug that into your shell's autocomplete, and you've got a fairly discoverable TUI, I think.

The best CLIs are interactive. Try a Cisco console. At any point they have a limited search space and you can just type "?" to get autocompletion for what you're doing. Everything is hierarchical and very discoverable. You can negate things with "no" to unset properties and such.

Even zsh with various plugins or fish feel rather primitive in comparison.

I typically write bash wrappers in situations like that. You could also write in a real programming language that shells out to the CLI tool if it gets too complicated.. even better if there's a library that does away with the need of shelling out.

CLI discoverability is much better when the utility has good support for completion. For example, kubectl, which can output its own completion script for different shells, and can complete things like resource names. I don't know much about how shell completion actually works, but I do appreciate it greatly.

Yes, but then you make aliases.

If my .flotsam_and_jetsam file gets lost, I don't think I know how to use a computer anymore.

That's why you check it into a Git repo. Right?

I disagree. I find both the Azure and AWS CLI more discoverable than their web UIs.

Yeah, I agree. Nothing beats google search and Stack overflow. If you has something later let that in the console it might be very nice indeed. `cloud-tool -h expand volume on pod` which would return examples, maybe even suggest ones based on your setup/configuration.

This comment sounds like a criticism of the way AWS is designed, not the concept of the CLI.

As someone who prefers CLI to GUI and works exclusively in CLI, I find the AWS CLI offerings no better than a GUI. AWS is a big ball of mud that keeps getting bigger. Commercial success does not change that fact.

Perhaps the point of starting with a CLI first instead of a GUI is that it creates limits, it favours simplicity and creativity. If you find yourself creating dozens of single-purpose utlities or one utility with dozens of options, then maybe you are doing something wrong.

Rather than looking to AWS as a model, why not look at something non-commercial, like djb's software or Wireguard. There is "power" in keeping a CLI simple.

There are probably alternative market segments for your approach. The AWS CLI is generated from the API, not the GUI. That is not CLI first either, but it follows the GIT approach of the CLI being effectively an API.

AWS is big and it keeps getting bigger. However that is not an argument for simplification. AWS does not add features because they don't know what else to do. They add all these features because they fulfill customer demand. Yes, you can come up with a dumbed down version of a cloud and wrap it in a beautiful CLI first approach. This might even work, you know, until people start picking up on it, feature requests come in... And then you are faced with either sticking to your original mission and serving a niche market, or breaking your promise for the potential gains in expanding your market share.

By building a CLI first approach, you need to be very good at positioning yourself in the market and picking the untapped potential. At either side, there be dragons and if profitability gets the better of you, that might very well be end of it.

I would rather have a CLI that wraps AWS or in general existing clouds behind a simple, friendly interface for common use cases. But of course you can't earn money with that.

> My point being: UIs (GUIs) are not just for non-power users—they are indeed for power users as well.

Hear hear. GitLab has ably demonstrated that their business model works and isn't replicable by hyper-clouds mostly due to making sure the UI is the differentiator (selling it at a premium) and not the APIs (in Micro's case, the CLI) [0]. Micro may want to focus back again on the UI, given they are more or less in the same domain (open-core devtools).

[0] https://www.heavybit.com/library/video/commercial-open-sourc...

Ultimately GUI vs CLI is false dichotomy.

GUI refers how information is represented to the user, and CLI refers how user interacts with the application. If not quite 100% orthogonal, they are two different aspects of the total UI, and there imho is plenty of room to go further and explore the space instead of fixating on some age-old patterns.

If you want adoption CLI only is a not a great choice. 90% of the developers and IT staff I work with are GUI only. A CLI only also means you need great documentation, still people won't read it and constantly ask for a GUI for simple things. Finally for those pointy hair bosses a CLI only service is hard to sign a check for, since they can't really "see it" even if you send a great invoice.

As a general followup observation, if you're building a system, that's probably a sign you're not your primary customer. The fact that you want a CLI-only SaaS is unlikely to be a good measure of what your potential customers want.

Hey (Micro Author and CEO here). I hear you. GUI is a thing that's hard to break away from with the point and click crowd. This is where "IT" people and old school sysadmins becoming devops people likely thrive with the AWS dashboard, but considering most devs are writing code and use Git we think the CLI first approach is really key.

To this point when we do anything on the web it will start purely as a CLI at m3o.com/cli and replicate the existing terminal experience, but maybe with some messaging like component so you can have nice emojis, rendering screenshots for graphs, etc.

When it comes to cheque signing (6-9 figure deals) from the people with the money, I'm sure at that point we'll have to do something to win them over but we're a long ways from it right now.

This looks really cool! Personally, I'd use it---web interfaces are getting increasingly annoying these days.

But do you have plans to release libraries for your API in major languages? Stringing together a bunch of shell commands in a bash script is also a little bit annoying... or at least much less friendly than doing the same thing with, say, a Python lib...

Thanks! Yes, so the CLI is the main consumption experience but Micro is geared towards services development, meaning we provide a Framework, CLI and Server that all work together. The CLI is mostly just proxying commands via a gRPC server and the entire thing is written in Go so everything we do in the CLI you can use the Framework to do in code. We also generate multi-language clients. Check out the 3.0 release announcement for more info https://micro.mu/blog/2020/11/05/micro-v3-aka-m3o.html

Git isn't a great proxy for cli usage. Many developers use git exclusively through a GUI or their text editor.

I use Git, hidden away in the comfort of my IDEs and desktop shell extensions.

When I started in computing, CLI was the only option, and I don't miss those days.

Good luck with your endevours.

> 90% of the developers and IT staff I work with are GUI only.

That's terrible - especially the part about the boss who cares more about toys than productivity and delivery. I hope you can find a way to demonstrate your skills to a talented team who in turn can offer sane working conditions.

> the boss who cares more about toys than productivity and delivery.

It is terrible, but very common in my experience. It is the success recipe for Apple to a large degree.

Software houses are something different, but if you change to another industry as inhouse dev, the priorities change drastically. It has advantages and disadvantages, but in industry jobs outside of software people just cannot really evaluate the quality of your work. It just needs to look shiny to a degree.

That is terrible. As a "boss" of an SRE team, we only use the GUI for groking, testing (in a sandbox account), and for a handful of _documented_ things that have to be done in the GUI (usually account wide settings). Everything else, in every "real" environment is in source control, we use Terraform.

Implying that there's something wrong with folks that prefer a GUI to a CLI, and that these people are somehow less talented...

Anecdotally this has been my experience. Just one sample size out of many but I do prefer working with people who share an affinity for CLI.

I don't think it's an issue of talent. But a preference for GUIs often hampers people and the work they support. You can't compose GUIs like you can CLIs, and that's important as your workflows become more complex and need to involve more things. You can either extend the GUI (Hah! only if you own it or it's open source) or develop manual processes, or use tools that can automate GUIs but tend to be fragile.

> You can't compose GUIs like you can CLIs

You can, actually, but few companies bother to do it.

There are quite a few apps with macro functionality, where each GUI option is also a command and you can record those commands.

I imagine they have too few users who use that functionality so that's why they're so rare.

By compose I think they meant use two different guis in the same workflow, sort of like how you can pipe the results of one command into another.

As mentioned on a sibiling thread, when I started in computing CLI was the only option and I don't miss those days.

Xerox Computing / Lisp Machines >>>> UNIX CLI

My affinity for CLI boils down to Powershell capabilities over classical UNIX shells, including having a REPL and debugger.

> are GUI only

the "only" really does imply that for me.

I love cli, absolutely love using it whenever I can. But I totally agree with you. A lot of my own team (including great developers or technically competent people) prefers GUI and I was always surprised at that but I have given up fighting that battle trying to get everyone to stick to CLI as much as possible :). There must be a reason why people prefer GUI even though cli freaks like me don't get it.

This isn't the "fault" of CLI itself so much as bad documentation, but for Azure at least it's sometimes difficult if not impossible to find the insane CLI command which corresponds to a fairly basic operation in the GUI. So even though I'm very much a CLI person I frequently find myself in the Azure GUI, just because there's no other way to get stuff done.

GUIs definitely have a place.

For example, while I am fairly proficient with the git cli and everything, I would never renounce to the comfort of gitk.

It's just simpler, faster and more intuitive.

I think guis are more useful for things you don't do everyday.

I'm a cli junkie, but if I'm only going to do something every 6 months, it's not worth the mental effort to remember. I could be using that mental energy for learning obscure git subcommands and trying to shoehorn them into random situations I find myself in.

Here's one reason to prefer a GUI: input validation as you type.

> 90% of the developers and IT staff I work with are GUI only.

That's weird to me, but I'm in the embedded space. GUIs aren't scriptable (or aren't easily scriptable) which, for me and the teams I've been in, has basically been a no-go. If we can't script it, we can't automate it (easily), so we don't want to use it. A GUI + (good) CLI is a reasonable compromise. GUI helps us do some things, explore the tools/space, and then the CLI for all our automation.

> Finally for those pointy hair bosses a CLI only service is hard to sign a check for, since they can't really "see it" even if you send a great invoice.

Again, weird to me. But also still the embedded space. We buy tools with no GUI (or an awful one, but a decent CLI) all the time.

This is my experience in the cloud space as well. Sure, AWS has a GUI, but the API & CLI are what we care about.

> GUIs aren't scriptable

> If we can't script it, we can't automate it

That's the point! In my team in Amazon, a candidate unfamiliar (or hostile to) CLI would be a strong no hire.

"If you want adoption CLI only is a not a great choice."

As a CLI only cloud storage provider, I can tell you that the upside to this is dramatically reduced technical support requests.

Further, attack surface is also reduced. I sleep very soundly at night knowing that nothing but TCP22 can come into our cloud platform.

"90% of the developers and IT staff I work with are GUI only"

Please don't tell them about rsync.net. They'd hate it.

UX Designer here with a long history in developer services.

Build what your customer needs.

Most often for PaaS offerings that is actually a robust, well documented, and principled API design.

CLIs come in a very close second.

GUIs tend to add real value for observability and operational management, but very little for composition or configuration.

Use the right form of experience for the workflow, data, and familiarity of your customers.

“Build what your customer needs” is spot on and needs an additional emphasis.

Precisely. As long as you're not doing CLI for "ideological" reasons, sure, go for it if it's what customers want.

Something to keep in mind when you eventually _do_ launch a GUI is to make sure it and the CLI are using the same flows, concepts, etc. It can be really confusing to use a GUI that does things one way and a CLI that does thing a totally different way!

I think being CLI-first (and maybe API-first) is a really clever strategy. My gut feeling is that it’s much easier to get a CLI/API right than to get a GUI right. So you can just expose an API or a machine-parsable CLI, and let people who care enough to build their own wrapper GUIs the way they want.

Whenever I make a desktop application, this has been my strategy and it's usually been effective. Create a library for the core logic and various CLIs using the library to expose functionality (also helpful for creating automated tests of larger chunks of functionality). Then create a GUI that essentially wraps those same features in a pretty presentation and (hopefully) intuitive interface.

Not everyone has liked my approach, though. And some managers have scrapped it even though the users (usually these are internal tools, so our teammates) liked it.

Another advantage of this style is that, for me at least, I tend to get a better design out of the system which makes that "library" portion more reusable. In theory, that CLI tool can become a GUI or become a server application as well without having to change the core code. But many people (and I sometimes fall victim to this as well) when making a GUI integrate the business logic too tightly with the GUI code (the same with web services). Something about making a CLI makes it easier for me and many people I've worked with to make a clearer delineation between the core logic and the interface logic. Perhaps because we know the CLI isn't the final or only presentation.

And I suppose that this kind of approach should make it easy to make several wildly different UI's :

- one desktop keyboard & mouse GUI

- one small touchscreen GUI

(- who knows, one day a Virtual Reality GUI ?)

The main appeal of Command-Line Interfaces is repeatability. GUIs are hard or impossible to script, but CLI commands can be followed, typed in or copy-pasta'd.

The main appeal of RESTful interfaces is discoverability and semantic CRUD conventions. Now if only I could remember the CLI arguments to `curl`...

curl --help

man curl

Remember the commands, not remember how to look up the commands ;)

A potential advantage of using just a CLI would be that you could use SSH authentication, with public key cryptography. It would be much more secure, especially for a VPS provider, where if your SSH key gets cracked it's game over anyway, so that the password is only an additional security risk.

I think the post has some valid points, developing front-end dashboards nowadays is a pretty big undertaking and if your userbase doesn't require it, why would you?

I can see some future expansion into the webspace as a premium feature like serverless.com does.

Thanks! Author here. I believe that's the key takeaway, knowing your audience and being able to do things that are perhaps controversial. In our case, it's also focusing on our strength while we are such a small team. Being mostly backend devs (although many of us launched products where we did the full stack) CLI is in our DNA. We believe if the product and experience is not compelling enough, having a shiny GUI won't help. Then why waste the effort instead of making our core proposition stellar?

Related to this post. M3O is now open to the world. If you're interested in that CLI first experience check out the announcement post.

https://blog.m3o.com/2020/11/05/m3o-open-to-the-world.html

I am working with Heroku these days and I find that the CLI experience they offer is really great and seamless.

I totally disagree. Heroku CLI is a mess, the API is not much bette - neither are consistent with the web app, including missing ability to perform manifest based deployments!

Im sure if you are doing trivial stuff, its adequate, but its really poor IMHO.

It is a bit offputting that the install script expects sudo rights just to copy a file from a user-readable directory to a user-writeable directory.

That is literally the only place where sudo is used, so it should be removed. (After removing it myself, everything still set up okay -- not a surprise.)

This is really interesting. I happen to dislike GUIs wherever it comes to any kind of software development. CLIs are just more programmatic, and I happen to be comfortable with programming. I've thought quite a bit about this while working on Pragma [0]. I think GUIs offered by BaaS (e.g. Firebase or Hasura) just aren't efficient compared to writing everything in files and using Git and my favorite text editor to work with it.

[0] https://pragmalang.com/

Azure CLI works great and you can do everything with it. Often times, especially with new features, they go CLI first and then slowly migrate things into the GUI.

On the other hand, Azure GUI is way faster for me to get stuff done in as a casual user, and if they didn't have a GUI I doubt many people would use Azure.

This is awesome seeing a paas optimize for expert users before planning how to expose those features more broadly. I hope their documentation follows suit!

CLI is great for playing around but IMO an even more important interface is the one to provision the state of the PaaS, e.g. a Terraform module.

This is awesome and I think the point here missed is that the audience of this PaaS are experts who do not have a hard time with a CLI. I personally would not hire a Devops person who could not navigate a CLI but I am not experienced in HR either. Great job.

Is this go only? I don't have numbers but I rarely see go backends, I wonder if the market your addressing exists / is big enough.

Going CLI is an interesting concept!

Having a gui is useful when you're dealing with different services and you don't have the muscle memory to do some operations quickly. It's easier to get something out of aws-cli than that horribly complicated frontend. Npm is somewhere in between: some operations are easier from the cli, other from the GUI. Digital ocean has a snappy and simple ui, I don't miss a cli.

I would go with both and hire a frontender - even for cheap: just HTML can be another hill to die on.

IMO this is a great strategy to get off the ground.

Eventually, I don't think you'll be able to get around offering a web GUI because if you don't somebody else will build one for you (around your CLI tooling).

I've seen auto-generated passwords break bash and powershell alike. Please include a way to bind variables to something not parsed as process arguments - such as a pointer to a env var, Azure KeyVault key, AWS SSM key or just the raw contents of a file.

Watch out for template expansion hell. Azure DevOps provide multiple types of variable expansion: macro, template expression and runtime - this helps but has it's own limits.

Also I found arg forwarding with '-' with node cli tools rather powerful lately.

We've been CLI only for 10 years now.. :) Feel free to throw questions regarding response, support, etc. my way.

https://uberspace.de/ https://manual.uberspace.de/web-backends.html

I didn't find any way to try or register from Android. I mean, it looks like a blog ? I was able to click on the Github logo then to the link to your home page. But the menu 'explore' doesn't work for me..

Yet something else that I definitely need to try out as soon as possible. I generally don't like leaving the CLI, so this seems like it could work great for me.

AWS was CLI-only when it launched. It was fairly tedious TBH.

I wouldn't count Amazon screwing up UX against CLI tools. More a testament to Amazon and their inability to successfully implement good UX in both GUIs, webpages and CLIs.

I wouldn't count AWS as CLI-only.

The initial launch post was: https://aws.amazon.com/blogs/aws/amazon_simple_q/

> We’ve got sample code in C#, Java and Perl, and we also have a Windows Communication Foundation (WCF) Add-in.

They launched as API-only, and they gave you sample code for how to talk to their psuedo-rest-like API, and use of SQS was API only.

I don't know when the aws cli launched, but it was definitely a bit later.

I thought their launch post was this https://aws.amazon.com/blogs/aws/welcome/ back in 2004.

The original AWS blog was about "amazon e-commerse services".

They recycled the AWS name for their cloud stuff, and I don't count e-commerse services as AWS, even if they happened to share a blog.

AWS still is CLI-first.

Are infrastructure engineers likely to use a CLI?

This is the question that needed to be asked. What are the people building production with your PaaS going to use?

First and foremost, infra engineers use generally one tool to build their Infrastructure as Code (Terraform, Pulumi, Ansible, Puppet, etc). This is the heart of their deploys and whatnot, so they need robust tools that integrate with all the different services they use, handle deployment complexities, etc.

Second they use a [web] GUI. If you want to prototype something or throw together a quick MVP, you don't spend a week fidgeting with a console, you open a GUI and just make it work. If developers have access, they can prototype things very quickly. I also tend to then use Terraformer to spit out HCL for what I've created in the GUI, so I don't have to spend hours/days fucking around with making Terraform modules just to reproduce what I did in 5 minutes in the GUI. (hey, CLI writers: please don't intentionally make your tool a fucking pain in the ass just so your company can make more money off of consulting or whatever your excuse is, because now I resent your company for making my life harder rather than easier)

Next comes CLIs. Why are they third? Because you're not using them to prototype (see above) and you'd be using your all-in-one tool for long-lived IaC. The CLIs are used for quick hacks and investigations and the like. And of course they're all different, and most of their UXs suck, because the designers of them apparently have never used GNU tools before.

Finally come the APIs when nothing else works. Typically scripting something with bash and curl, or Python, Ruby or Node.js for those who aren't console cowboys.

look cool, but many cool thing fail in business

Is this go only?

Reply on news.ycombinator.com