"just picked a bad service boundary" -- well that's the thing isn't it. If you always pick the right boundary up front, something that is perfect both now and also anticipates any kind of future crazy feature request -- if you can pull that off I'd say any architecture will work well.
But most people get boundaries wrong some times. Sometimes very badly wrong. Sometimes the boundaries are historical, set by product owners without technical input, set by junior developer, set by superficial attributes, and sometimes even the most experienced developer-architect just does a mistake.
And the whole point of not doing microservices is you don't have a huge investment in your boundaries, it's more feasible to change them once you inevitably now and then realize you got them wrong.
Isn't the point of making services as small as possible so that you can easily shift boundaries? Isn't DDD (a common companion of microservices) all about constantly shifting business domains?
We've gotten boundaries wrong tons of times. We change them, which includes a migration script to move historical data from one service to another, if possible. Yes, it's work, but it's not any more work than having everything crammed into the same monolith and having to deal with all the downsides therein.
Well the parent talked about not joining across services. Then there are hard limits to how small you can make them.
And what need to join with what is something that can change.
So if you make services very small, and no joins across services, you get a lot of copies of the same data everywhere...
And if you make the services too small you have just moved the exact patterns you would have inside a monolith to into your APIs..how can that be easier?
You say "downsides of monoliths" but monoliths isn't a homogenous thing, they come in all shapes and varieties. So does microservices.
Myself I happen to have experienced microservices systems that are a real mess, and pretty clean monolith designs. Consider for instance an event sourced service where every endpoint a) reads events from database, b) if business rules allows (involving possibly external calls) writes an event to the database. No CRUD. This pattern keeps every handler/business rule reasonably isolated from other, and it doesn't matter if it runs in 1 or 10 services...
Reports and statistics, especially on material that crosses service boundaries (but even on single-service information, to keep services single-responsibility) are their own logical services, which operate on copies of data received from (often multiple) upstream services. (In many real world cases, you’ll want this functionality in a data warehouse, but there are some cases where some of it may be in something that looks like normal services, whose data that can change other than by push from other services deals with reporting and report-delivery configuration, not the business data on which reporting is done.)
Seems like a straw man.