[geezerjay]

I don't believe it os reasonable to portray microservices as the result of incompetence and blame-shifting.

Microservices are actually a very basic and fundamental principle of software engineering: separation of concerns. If your system is extensive enough so that it covers multiple independent concerns and your team is large and already organized into teams focused on each concerns then it makes technical and organizational sense to divide the project into independent services.

[taneq]

They're subject to a clear limit, though. The more micro you make your services, the less they resemble operational units and the more they resemble primitives from which your actual system is built, sort of like an inner-platform effect. And then you have to debug interactions between microservices, with all the overhead that entails.

[mrfredward]

Separation of concerns is important, but how much separation do you need? Separate classes, definitely. Separate libraries...often. Completely separate services on different VMs with an api between them...if that is really what your situation requires, then sure, but I wouldn't make it the default option.

The mistake is when people think a buzzword is the new best practice without doing real analysis.

[leni536]

Isn't separation of concerns addressed by modularization? Of course using microservices is one kind modularization.

[nasmorn]

Is large is a key phrase here. I am seeing many times now that teams build more services then they have members. This only pushes separation of concern into the network layer when it could just as well be in a module or class level.

You can tightly couple services too, you know. I would say it is a good option to have but suffers a bit from too much popularity right now. People are using it for its own sake.