Bad arguments for microservices

There are already many great articles about good and bad microservices design. There is also an enormous amount of bad articles showing the bad design of microservices as a pattern. And a huge amount of teams who fell into that trap. The truth is: You may not need microservices, this is not a silver bullet. But you definitely need modules.

Here are some arguments for microservices I’ve heard too many times.

Microservices are simple and “lightweight”

I need microservices for modularization

I need product service, user service …

Maybe these domains are good candidates for microservices…

I need microservices to scale-out

I need to handle different vectors of changes

Everyone does it

Do you want me to create monoliths then?

Think about what problems do microservices solve? The same as SOA did years before but with better tooling. It is developer-driven rather than a vendor-driven approach to services architecture in large organizations. Decoupling monoliths with ESB at a heart of the system just moved the whole complexity into ESB making it a monolithic ball of wool. With microservices and APIs, the IT industry is running away from SOAP and ESBs.

Think: Do I have such problems?

Modules have different scaling characteristics

You need releases at a different frequency

I need to support multiple domains

You need to use the right tool for the job

You have different security/privacy/reliability requirements for modules

A piece of the system that handles sensitive data (e.g. storing credit card numbers will require PCI DSS compliance) may have additional protection means that usually comes at additional cost and reduces flexibility. It is a good idea to limit it to a dedicated microservice.

You need multiple teams working on your system

If you find out that you need to release the whole system of microservices together, what you’ve built is a “distributed monolith”, which is the worst kind of it.

The anti-corruption layer is needed

Links from “My bookmarks” still valid in 2020:

Originally published at

Cloud Solution Architect at GFT. Helping financial organizations making best use of cloud.