At the start of this hectic year I have joined Micro, an open source microservices platform. The company was born out of a Go framework. We took the concepts of the framework - interfaces for service discovery, configuration and other pieces which can run on any implementation (from mdns locally to kubernetes) and provide a live platform version of it. It’s kind of like Netlify, but for the backend.

Once we were happy with the local development flow for the micro server and CLI, we decided to start selling the product as a platform. Building a website seemed like an obvious step to do. It’s 2020 right?

So we got to work. Metrics with nice charts. Tracing. Calling services. Listing endpoints. It was all shaping up nicely. But slowly and surely we started missing features we got accustomed to on the frontend in the CLI. Being very heavy command line users, whenever we got something available in the CLI, we reached there first.

And then we realised. Who are we building this frontend exactly and why? We prefer the command line. And none of our many thousands of users were asking for a web UI. At most it was considered a “cool” thing to have.

The past three decades have been all about the world wide web (www) and in that we’ve gone through the multiple iterations of building “web first” experiences which I’d argue really peaked in the Web 2.0 era in the mid 00s with the likes of Facebook and others. At some point we entered the “Mobile first” era and yet for developers, Web still became a horrible platform we were stuck with for any platform or tools, AWS is a great example of how to get it really wrong. If new products and platforms are going Mobile first, maybe we as developers need to go CLI first. So here it is. M3O is a CLI first experience. No context switches, no ugly dashboards, just a simple straight forward command line utility that gets out of your way when you need it to. Our hope at Micro is more learn from this experience and do away with Web UIs entirely. Challenge every assumption you know about Web for backend development and think, do I really need that, or is it better served as a single CLI experience.

So we doubled down. We entirely sidelined the web UI and decided payment will be the only thing on the website, should supplying card details in the terminal feel sketchy.

What we found after this surprised us. By limiting our choices we unleashed a storm of ideas on how to improve the single medium we can express our thoughts in.

We started to make service call feel just like any command invocation.

What was previously

micro call servicename endpoint '{"field":"value","otherfield":{"subfield":"value2"}}'

became

micro servicename endpoint --field=value --otherfield_subfield=value2

On the surface it might not seem much, but when you are living and breathing these commands it provides a great satisfaction to remove even little frictions.

New services and their endpoints feel just like builtin Micro commands, which is why our invites simply became

micro invite user --email=someone@domain.com

Shipping features to end users became as deploying a new service, and users can easily programatically call their endpoints from the terminal.

Bash shines at quick and information dense throwaway scripts, so our end to end test framework is built for tests to be written using Micro CLI commands.

We dream of a future where programming is as close to natural languages as possible. At the moment, the ubiquity of bash provides a great layer for us to quickly interact with microservices. It truly feels like the platform is alive as nouns and verbs are being created by service writers to be composed into sentences.

Why don’t you give it a go? We have a free tier ;).

Co-Authored with Asim Aslam.