CLIs (Command-Line Interface Applications in short) are a damn useful way to facilitate automation. It has one type of input (strings) and one type of output (again strings). Simple, but very fast and effective, also loved by productivity junkies.

This is a blog on asking whether CLIs can be used along with microservices effectively. Because I used it in one of my use cases, and it resulted in major performance and stability for the overall solution.

So why CLIs in the first place? …
Well the list says

• Doesn't take up lots of space. Generally tiny binary sizes compared to GUI counterparts.
• Depending on the size of tasks, CLIs generally don't crash as OS usually switches to swap to free up memory when RAM is at full capacity.
• Easier to develop

But we already have servers for that …. right?

Well, kind of …. even servers are bins and scripts running on the machine, but are very complex. A server has more points of failure than an installed binary. Also updating said binaries is a breeze, just replace the file with a new one.

So, does 1 BIG CLI app that can do all the necessary tasks on the server when deployed be enough? Well, it depends. If the number of tasks to be performed on the server is minimal, then yes. But, if there are 2 or more different tasks, that have a common task to be performed, then distributing the tasks into multiple CLI is beneficial. Let me explain this tho …

Let's say there is a pipeline setup where the repository is cloned, and built and the binary is uploaded to another path. There are 3 tasks on the top layer, they're clone, build and upload. These 3 tasks can be written into 1 binary. But, if you want to add another pipeline, with a bit different build and upload process, you may choose to add it to the same CLI using options. That will work, but in the long run, code maintenance will be complex. So, it's better to split the tasks into 2 different CLIs, one for the first pipeline and another for the second pipeline. This way, the code is easier to maintain and update.

So the clone part of the pipeline is common for both pipelines, so it can be written into a separate CLI. The build and upload part of the pipeline is different for both pipelines, so they can be written into 2 different CLIs. This way, the code for the clone can be maintained in only 1 place.

This is the basic idea of micro CLIs. They're small, simple and easy to maintain. They're also easy to update and deploy. They're also easy to test and debug. They're also easy to scale. They're also easy to monitor. They're also easy to secure. They're also easy to document. They're also easy to use. They're also easy to integrate. They're also easy to …. you get the idea.

This is how I used micro CLIs in my automation solution provided in my previous organization's hackathon. I automated a task that could be deployed by any server. The task to be automated was time-consuming and a few modules in it separately could be used by other teams' solutions to speed up their solutions. That's when I architected the solution to be a micro CLI. It worked like a charm.