Libraries are great, but you can't deploy new versions of library without needing to step on toes. If your dev teams are just "shove this at ops" and done, then it may not make a difference, but if you need to be responsible for the code running in the real world, just library segregation doesn't cut it.
I'm being dense it seems, because I don't see what microservices brings to this. What's the fundamental difference in this regard between shipping an executable with a bunch of dynamic libraries, and deploying a bunch of microservices?
It's mostly about data. Each micro services is responsible for their own data, data migrations, data store, etc. Think of it as a mini web app with an API. In theory, you could use a library in that way but I have never seen such use in practice. You would also run into the problem of having to always keep all library users on the latest version as to avoid having two versions which expect different database schemas. It also largely forces you to stick to a single programming language.
Conversely though, if you can make do with a single data store and data layer (orm or just simple queries) the libraries can use that.
The schema and generated classes could be a shared common library that different teams can work on (maybe with some architecture obersight)
Or if using schema-less each library “knows” it’s own json formats
Then you get nice things like atomic transactions across multiple “services”. You also have no network concerns.
You can pull out microservices for things that need special attention. Such as a spikey-load service that might need to run as a lambda.
Version management is a solved problem. Use your languages package manager and semantic versions.
I concede you need to stick to one language. Ish. You have C FFIs. A .NET app could reference a dll written in C++ or Rust. But yeah not as flexible as services. Although there are inbetween things like RPC.
