12 ms·

We are building a CLI first PaaS without a web frontend

153 points by friendly_chap 6y ago

PretzelFisch 6y ago
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.
- yodon 6y ago
  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.
- asim 6y ago
  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.
  - paultopia 6y ago
    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...
    - asim 6y ago
      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 https://micro.mu/blog/2020/11/05/micro-v3-aka-m3o.html
  - ball_of_lint 6y ago
    Git isn't a great proxy for cli usage. Many developers use git exclusively through a GUI or their text editor.
  - pjmlp 6y ago
    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.
- officialchicken 6y ago
  > 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.
  - raxxorrax 6y ago
    > 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.
  - actionowl 6y ago
    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.
    - deleted 6y ago
      [deleted]
  - RhodesianHunter 6y ago
    Implying that there's something wrong with folks that prefer a GUI to a CLI, and that these people are somehow less talented...
    - mrmonkeyman 6y ago
      Artists that paint by numbers are less talented. Oh wow, such a daring thing to say. Of course folks who get scared of a terminal are less "talented" at hardcore IT. That's like a painter being afraid of palets and brushes.
- codegeek 6y ago
  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.
  - Analemma_ 6y ago
    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.
  - znpy 6y ago
    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.
    - ByteJockey 6y ago
      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.
  - elbear 6y ago
    Here's one reason to prefer a GUI: input validation as you type.
- Jtsummers 6y ago
  > 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.
  - mainstreem 6y ago
    This is my experience in the cloud space as well. Sure, AWS has a GUI, but the API & CLI are what we care about.
  - ex_amazon_sde 6y ago
    > 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.
- rsync 6y ago
  "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.
JrProgrammer 6y ago
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.
- friendly_chap 6y ago
  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?
dennyabraham 6y ago
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!
cjauvin 6y ago
I am working with Heroku these days and I find that the CLI experience they offer is really great and seamless.
- supermatt 6y ago
  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.
jbirer 6y ago
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.
jahewson 6y ago
AWS was CLI-only when it launched. It was fairly tedious TBH.
- capableweb 6y ago
  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.
- TheDong 6y ago
  I wouldn't count AWS as CLI-only. The initial launch post was: https://aws.amazon.com/blogs/aws/amazon_simple_q/ 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.
  - cow9 6y ago
    I thought their launch post was this https://aws.amazon.com/blogs/aws/welcome/ https://aws.amazon.com/blogs/aws/welcome/ back in 2004.
    - TheDong 6y ago
      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.
- kondro 6y ago
  AWS still is CLI-first.
mrstumpy 6y ago
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.
- Closi 6y ago
  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.
RocketSyntax 6y ago
Are infrastructure engineers likely to use a CLI?
- peterwwillis 6y ago
  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.
pgt 6y ago
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`...
- enriquto 6y ago
  curl --help man curl
  - notsuoh 6y ago
    Remember the commands, not remember how to look up the commands ;)
spelunker 6y ago
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!
k_sze 6y ago
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.
- Jtsummers 6y ago
  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.
  - deleted 6y ago
    [deleted]
  - BlueTemplar 6y ago
    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 ?) ?
    - deleted 6y ago
      [deleted]
luto 6y ago
We've been CLI only for 10 years now.. :) Feel free to throw questions regarding response, support, etc. my way. https://uberspace.de/ https://uberspace.de/ https://manual.uberspace.de/web-backends.html https://manual.uberspace.de/web-backends.html
Tehnix 6y ago
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.
- anoncake 6y ago
  There are plenty of GUIs less discoverable than a documented CLI with completion.
  - notsuoh 6y ago
    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.
    - anoncake 6y ago
      They simply don't. Good GUIs lead to better discovery.
      - adamisom 6y ago
        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".
- tejohnso 6y ago
  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.
draw_down 6y ago
Yeah I mean, if you want a web frontend you have to dirty your hands writing, yecch, JavaScript. Horror of horrors.
amadeuspagel 6y ago
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.
brightball 6y ago
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).
kostarelo 6y ago
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.
ritonlajoie 6y ago
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..
deleted 6y ago
[deleted]
qxmat 6y ago
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.
nurettin 6y ago
Is this go only?
asim 6y ago
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 https://blog.m3o.com/2020/11/05/m3o-open-to-the-world.html
Tabzz98 6y ago
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/ https://pragmalang.com/
asymptosis 6y ago
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.)
noen 6y ago
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.
- gabereiser 6y ago
  “Build what your customer needs” is spot on and needs an additional emphasis.
- ineedasername 6y ago
  Precisely. As long as you're not doing CLI for "ideological" reasons, sure, go for it if it's what customers want.
luord 6y ago
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.
jokethrowaway 6y ago
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.
tinybug 6y ago
look cool, but many cool thing fail in business

153 points by friendly_chap 6y ago

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.

yodon 6y ago
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.
asim 6y ago
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.
- paultopia 6y ago
  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...
  - asim 6y ago
    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 https://micro.mu/blog/2020/11/05/micro-v3-aka-m3o.html
- ball_of_lint 6y ago
  Git isn't a great proxy for cli usage. Many developers use git exclusively through a GUI or their text editor.
- pjmlp 6y ago
  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.
officialchicken 6y ago
> 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.
- raxxorrax 6y ago
  > 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.
- actionowl 6y ago
  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.
  - deleted 6y ago
    [deleted]
- RhodesianHunter 6y ago
  Implying that there's something wrong with folks that prefer a GUI to a CLI, and that these people are somehow less talented...
  - mrmonkeyman 6y ago
    Artists that paint by numbers are less talented. Oh wow, such a daring thing to say. Of course folks who get scared of a terminal are less "talented" at hardcore IT. That's like a painter being afraid of palets and brushes.
codegeek 6y ago
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.
- Analemma_ 6y ago
  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.
- znpy 6y ago
  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.
  - ByteJockey 6y ago
    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.
- elbear 6y ago
  Here's one reason to prefer a GUI: input validation as you type.
Jtsummers 6y ago
> 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.
- mainstreem 6y ago
  This is my experience in the cloud space as well. Sure, AWS has a GUI, but the API & CLI are what we care about.
- ex_amazon_sde 6y ago
  > 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.
rsync 6y ago
"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.

JrProgrammer 6y ago

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.

friendly_chap 6y ago
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?

dennyabraham 6y ago

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!

cjauvin 6y ago

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

supermatt 6y ago
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.

jbirer 6y ago

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.

jahewson 6y ago

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

capableweb 6y ago
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.
TheDong 6y ago
I wouldn't count AWS as CLI-only. The initial launch post was: https://aws.amazon.com/blogs/aws/amazon_simple_q/ 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.
- cow9 6y ago
  I thought their launch post was this https://aws.amazon.com/blogs/aws/welcome/ https://aws.amazon.com/blogs/aws/welcome/ back in 2004.
  - TheDong 6y ago
    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.
kondro 6y ago
AWS still is CLI-first.

mrstumpy 6y ago

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.

Closi 6y ago
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.

RocketSyntax 6y ago

Are infrastructure engineers likely to use a CLI?

peterwwillis 6y ago
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.

pgt 6y ago

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`...

enriquto 6y ago
curl --help man curl
- notsuoh 6y ago
  Remember the commands, not remember how to look up the commands ;)

spelunker 6y ago

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!

k_sze 6y ago

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.

Jtsummers 6y ago
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.
- deleted 6y ago
  [deleted]
- BlueTemplar 6y ago
  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 ?) ?
  - deleted 6y ago
    [deleted]

luto 6y ago

We've been CLI only for 10 years now.. :) Feel free to throw questions regarding response, support, etc. my way. https://uberspace.de/ https://uberspace.de/ https://manual.uberspace.de/web-backends.html https://manual.uberspace.de/web-backends.html

Tehnix 6y ago

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.

anoncake 6y ago
There are plenty of GUIs less discoverable than a documented CLI with completion.
- notsuoh 6y ago
  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.
  - anoncake 6y ago
    They simply don't. Good GUIs lead to better discovery.
    - adamisom 6y ago
      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".
tejohnso 6y ago
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.

draw_down 6y ago

Yeah I mean, if you want a web frontend you have to dirty your hands writing, yecch, JavaScript. Horror of horrors.

amadeuspagel 6y ago

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.

brightball 6y ago

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).

kostarelo 6y ago

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.

ritonlajoie 6y ago

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..

deleted 6y ago

[deleted]

qxmat 6y ago

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.

nurettin 6y ago

Is this go only?

asim 6y ago

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 https://blog.m3o.com/2020/11/05/m3o-open-to-the-world.html

Tabzz98 6y ago

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/ https://pragmalang.com/

asymptosis 6y ago

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.)

noen 6y ago

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.

gabereiser 6y ago
“Build what your customer needs” is spot on and needs an additional emphasis.
ineedasername 6y ago
Precisely. As long as you're not doing CLI for "ideological" reasons, sure, go for it if it's what customers want.

luord 6y ago

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.

jokethrowaway 6y ago

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.

tinybug 6y ago

look cool, but many cool thing fail in business