I guess people writing microservices or services connected via the Internet didn't get the memo.
I have yet to find a single microservices architecture that could not be solved cheaper and simpler in some other way with less side effects. Plus there are some disparity between APIs and object distribution.
(Note I only work on non-google scale stuff where it is probably appropriate)
Edit: good example recently, I saw one where they implemented a complex distributed reservation pattern across microservices that gets about 100 transactions a day. They could have done it in one process with proper transaction isolation in a DB fine for about 1/100th of the total cost.
If you have 6 microservices and they're all being maintained by the same team of developers, you don't need 6 microservices. At most, I would grant maybe 2 - and that's simply because usually once something like payments and credit card handling get involved, for compliance reasons you want to really not touch it unless you have to - but that's still an organization boundary, just a self-imposed/PCI compliance based one.
Any distribution results in masked complexity and many hard to reason about scenarios even if the language or platform supports it transparently.
Ergo, just because you can doesn't mean you should, unless you want to discover them all, usually at an inconvenient point in the future when everything is broken and there's cash bleeding out of your org somewhere.