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...
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.