[negus]

Any arguments to support this claim? What's the difference then?

If there is three communicating servces: first has 90% of the business logic, second has 7%, and the last one has 3%. Should we call the first one a monolith? And if they don't communicate?

[crazygringo]

> Any arguments to support this claim? What's the difference then?

The "micro" in "microservice".

Microservices are meant to do one "micro" thing well, whether it's image hosting or credit card transactions or supplying the content of a tweet or whatever.

A monolith does all the things, or most of the things. It's not "micro".

You don't need arguments to support it, these are just the definitions of the terms. It's semantics.

A monolith can't be a single microservice because it's not micro.

[negus]

In my opinion it is too literal understanding of the concept and there is no universal borderline in size or scope. It is common in practice to find quite fat microservices because their maintaners decided it doesn't worth to have yet another network communication latency for a specific case.

The main problem here is to be able to effectively debug and maintain several communicating services: to have a distributed tracing facility like Jaeger, centralized logs collection, schema registry and so on.

It may seem compex to set up and maintain at first, but once you have some experience it does not add much toil and cognitive load. But having the infrastracture in place to effectively work with microservices gives you the freedom of system design choices. It does not force you to make microservices very small.

[JackSlateur]

You can have a single codebase, deployed in multiple kind of configurations

One code, multiple roles

[negus]

I mostly use statically linked monorepos with microservices. The services use the common utils from the repo. What's the difference except for not having dead code and unused dependencies in the artifacts in my case?