Where Microservices Are Actually Useful: Two Types of Use-Case

A few months ago I wrote a piece in defence of monoliths and then gave a talk about it. Overall, one should not jump to microservices, because the overhead and risk are much higher than any professed benefits. But there I left out some legitimate use cases for microservices.

These use cases may not be “typical” microservices, but they mostly conform to the notion of a separate, stand-alone deployment of independent functionality.

The most obvious use cases are those of a CPU or RAM intensive part of the application. That normally goes into a separate deployment, offering an interface to the rest of the application.

First, it’s easy to spawn multiple instances of a stateless, CPU-intensive microservice, on demand. They may even be “workers” that process a given spike and then die, including a fork-join setup. And they shouldn’t make the rest of the application get stuck because of their processing requirements – they should be separated.

There are services that consume a lot of RAM (e.g. text analysis tools that include big gazetteers, trained models, natural language processing pipelines) that are impractical to be run every time a developer starts the application he’s working on. They are even problematic to redeploy and restart in a production environment. And if they change rarely, it’s justified to separate them.

What’s common in those above is that they do not have a database. They expose their processing functionality but do not store anything (apart from some caching). So there is no complexity in coordinating database transactions, for example.

Another “partial” use case is having multiple teams working on the same product. That looks applicable to all projects out there – thousands of facebook developers are working on just facebook, for example. First, it isn’t. Many non-billion-dollar-billion-user companies actually dedicate one or a small number of teams to a project. And even facebook actually has many projects (mobile, ads, chat, photos, news feed). And those are not “micro” services. They are full-featured products that happen to integrate with the rest in some way. But back to the use case – sometimes microservices may give multiple teams increased flexibility. That very much depends on the domain, though. And it’s not impossible for two teams to work on the same monolith, with due process.

Universally, if you are sure that the network and coordination overhead of microservices will be negligible compared to the amount of work being done and the flexibility, then they are a valid approach. But I believe that’s rare. Martin Fowler talks about complexity vs productivity, so, in theory, if you know in advance how complex your project is going to be, maybe you have a valid microservices use case.

Separating a piece of functionality into a service of its own and communicating with it through web services should not be something that deserves so much attention. But apparently we have to say “no, it’s not for every project” and “yes, the approach is not dumb by itself, there are cases when it’s useful.”