I am trying to design a micro-services based SaaS application, where each micro-service would be packaged into their specific Docker container.

I also have a CLI tool (a binary file) that functions as a Swiss knife (i.e. does more than one thing) and there are a few micro-services that would want to use the tool's various functionality, making the tool important in the whole architecture. The tool can consume/produce a file or a stream.


I am unable to decide between the following:

  • Should I package the tool as part of each micro-service that needs it?
  • Should I package the tool as a separate service itself?

How does one decide between the two? Are there any other alternatives?


Each micro-service may need to spawn/access multiple instances of the tool at the same time. To elaborate further, the micro-service can use the tool multiple times, in sequence or in parallel to generate different outputs, which, later are aggregated and passed onto other services.

  • 1
    If this tool is called by other applications, rather than used by a human user, why is it a CLI tool rather than, say, a library that the applications can call into directly? If there's no reason for it to need to be CLI, then converting it into a at least a library, if not an entirely separate microservice, would certainly make some sense. Oct 26, 2017 at 13:49
  • I agree on having it in the form of a library. Alas, I lack access to its source, hence unable to do so.
    – Rishabh
    Oct 26, 2017 at 14:05
  • @Rishabh: If you don't have the source for the tool and given that micro-services are supposed to be accessed over a network connection, how were you thinking of turning the CLI tool into a micro-service of its own? How does that effort compare to your other options? Oct 26, 2017 at 16:00
  • @BartvanIngenSchenau I have to create a wrapper around it, which would actually invoke it.
    – Rishabh
    Oct 26, 2017 at 16:52

1 Answer 1


It depends on what the tool does and how frequently it will need updating.

If you package the tool with each service then an update to the tool means that you need to push out a corresponding update to each service that uses said tool. Packaging the tool as a separate service will mean that updates or fixes to that tool only need deploying in one place for all services to be affected by that update.

Depending on the tool either could be appropriate. For example a JSON parser would be better suited as a bundled library as it's very stable and unlikely to change significantly, so the overhead of having a separate service would likely not be worthwhile. A tool that does some sort of business calculation however might see frequent updates making it better suited as a separate service, especially if it's important to have consistency between services.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.