Microservices keep happening because we are bad at managing teams who's output is a library. We lack the tools to measure the "impact" of libraries during performance reviews. We can measure the number of calls to a microservice, but it's rare to measure library usage directly. When your library team needs to justify its budget, it doesn't have as much to point to.
It's also harder to assign blame for performance issues when your teams write libraries. In microservice, your team can isolate exactly how much CPU usage your code takes. But few companies can isolate the performance cost of a library. When your main service goes down, it's tricky to assign the responsibility to a single team to fix.
Finally, microservices give you ironclad control over your API surface, while in many companies other teams can often call into any part of your library. As other teams grow tendrils into your team's code, your support burden grows and you have to keep supporting unintended parts of your API.
Now all of these are fixable, and I think we should fix them. Writing and using libraries is easier and lower overhead than putting network calls everywhere. But until you fix the above issues, companies will keep sliding into microservices.
I don't think that distinction matters. Libraries can easily encapsulate data.
I think he's right - microservices are very often used in situations where a library is clearly the right tool for the job. In my experience the main reasons people don't use libraries are: a) the people in charge of the place where you should put the library are too territorial, so it becomes easier overall to start an entirely new project and deal with the very large downsides of microservices, and b) they want to use a different language, and disappointingly FFI over HTTP is usually easier than "true" FFI.
It's also harder to assign blame for performance issues when your teams write libraries. In microservice, your team can isolate exactly how much CPU usage your code takes. But few companies can isolate the performance cost of a library. When your main service goes down, it's tricky to assign the responsibility to a single team to fix.
Finally, microservices give you ironclad control over your API surface, while in many companies other teams can often call into any part of your library. As other teams grow tendrils into your team's code, your support burden grows and you have to keep supporting unintended parts of your API.
Now all of these are fixable, and I think we should fix them. Writing and using libraries is easier and lower overhead than putting network calls everywhere. But until you fix the above issues, companies will keep sliding into microservices.