It's the thing you reach for when you're hiring a new team worth of developers every other week and can't avoid developer blockage any other way.
It's not even a good architecture for most of the things it ends up being used on.
There are very few problem sets that a microservices arch actually excells at.
Almost always a monolithic with some SOA and clear domain boundaries is going to work better for static/slow growth teams.
It might be exciting for some but I wouldn't wish it on anyone.
If it has “some SOA and clear domain boundaries” its not a monolith, even if it isn't decomposed so far as to be microservices.
“Right-sized services” isn't a catchy meme-spreading label, but it's probably the synthesis pointed to by microservices as the antithesis to monoliths.
It doesn't say anything about not being able to be broken into modularized sections, services, or domain boundaries.
Neither does it reject any setups where satellite systems, micro or otherwise make use of the monolith programmatically or otherwise, hell it's kond of part of the definition of a monolith that it has multiple access points (i.e. cli, sdk, rest, rpc, events.)
Exactly my thoughts - all of the benefits discussed are centred around source code management, specifically, things tied into the source code management which have poor separation of concerns: ungranular tests, ungranular CI...
This doesn't have anything to do with it being loosely coupled code that aught to have an API and then _maybe_, _potentially_ is amenable to being run as a separate service and is worth the cost of that complexity.
Furthermore this article fails to list any sensible alternatives. For example, if you have different rates of change you simply need a good separation of concerns with clearly defined boundaries and interfaces. You can do this equally well in a monolithic application, with none of the distributed computing issues.