It's funny because the term "microservices" picked up in popularity because previously, most "service-oriented architecture" (the old term) implementations in large companies had services that were worked on by dozens or hundreds of developers, at least in my experience. So going from that to services that were worked on by a single development team of ~10 people was indeed a "microservice" relatively speaking.
Now, thanks to massive changes in how software is built (cloud, containers et al) it's a lot more standard for a normal "service" with no prefix to be built by a small team of developers, no micro- prefix needed.
I can understand wanting to split things off so that one team handles one service, roughly.
There was a recent thread here where someone mentioned he personally was responsible for about four of their microservices...
Yeah, my last company had 10 microservices (the entirety of their codebase) managed by a single team when I started. Some of them had fewer than 5 API endpoints (and weren't doing anything complex to justify that).
That may be true, but the article describes a services architecture and labels it microservices, indeed goes onto to say:
> The term micro can be misleading, though - there doesn’t have to be anything micro about the services
Yes, but the "widespread meme" as I see it is about microservices, not services in general.
The smaller the service, the more likely that the overhead of having a separate service exceeds the benefit of doing so. It isn't at all normal for a service to have its own database unless it provides a substantial piece of functionality, for example, and there are non-trivial costs to splitting databases unnecessarily. If you are not very careful, it is a good way to make certain things a dozen times slower and a dozen times more expensive to develop.
This seems subjective. It's like putting "compatible with the character of the neighborhood" in a city's zoning codes.
_Microservices_ attract the criticism. It seems to assume something about the optimal size of services ("micro") that probably isn't optimal for all kinds of service you can think of.