As far as I can tell, there's no reason why any of the constraints you have described could not be solved with libraries, and a function call is always going to be less complex than a network request.
That has a huge impact because now you need to set up the data store and potentially perform migrations, which means you may need to change how you do deployments. It may introduce a bottleneck such as number of connections to that store, so you now have limitations to think about when scaling.
If you're using libpng to edit an image on your disk you are working with both state and a data store. Yet plenty of applications do this every day without feeling a need to call it over a network.
And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network?
You would not. The HTTP (say) API objects are versioned separately from the DB (or any internal implementation detail) of the service. This is abstraction: your API interfaces don’t change despite any internal changes.
To illuminate this a bit more suppose you do share such a library anyways. Having 2 independent services let’s you upgrade each of them independently. You aren’t forced to update all of them at once.
This is exactly the same as how libraries are supposed to be written. A stable public API so the user doesn't have to bother with internal implementation details.
> Having 2 independent services let’s you upgrade each of them independently. You aren’t forced to update all of them at once.
You aren't forced to do that with libraries either. You don't have to statically link them at compile time, you can load them whenever you please.
> And if you have to set up and migrate a client/server DBMS for the library, wouldn't you also have to do the exact same steps as if it was running as its own process somewhere the network?
No only the team doing it has to. Users of a service only have to worry about the API that it exposes, which should ideally never change in backwards incompatible ways and if it does, you make sure everyone calling the API understands it and migrates and you break backwards compatibility only after everyone has migrated.
As a user the implementation details of other services I don’t work on, don’t concern me.
Note that a service equivalent to libpng should probably not exist and be a library instead. A more reasonable service would be a wishlist service that keeps track of every customers wishlist and sends notifications to customers when products on their wishlist get discounted or are back in stock.
No, it does not mean that at all. Where are you getting this idea from?
> Users of a service only have to worry about the API that it exposes
Users of a library only have to worry about the API that it exposes too. What kind of libraries have you been using?
> Note that a service equivalent to libpng should probably not exist and be a library instead. A more reasonable service would be a wishlist service that keeps track of every customers wishlist and sends notifications to customers when products on their wishlist get discounted or are back in stock.
What's the difference between the two? The only difference that I can see is that the libpng and libwishlist wouldn't waste a network round-trip and lots of serialization and deserialization compared to a png service or whishlist service.
Same problem applies, if your library suddenly wants to access another service (like S3 or some other AWS service).
You can of course maintain a stable API in a library and you should but that restricts the changes you can do to that library. A service I could rewrite in another language without users noticing.
If you're going to rewrite it in another language, what difference does it make if it was a library to begin with? There's no point in making all the upfront work in both the service and all the clients making them talk on the network on the off chance you need to do a rewrite in another language, when you need to rewrite the API layer too. The only thing that would over after the rewrite is the client code. Doing it risks having wasted time doing a network API level on both client and server for nothing, not doing it just risks having to do it when you need it. Doing a rewrite "without users noticing" has no real benefit here.
Where does the redis instance come from? How does the library get access to it?
These are problems the library author cannot solve and end up being problems for the user. Much like monitoring of that redis instance will also become a problem for the user.
Same place as it would if it was a microservice. Someone has to provision it, this is not automatic just because you use microservices.
> How does the library get access to it?
How does the microservice get access to it? A common way seems to be reading a host and port from an environment variable. Nothing is preventing a library from reading from an environment variable too.
> Much like monitoring of that redis instance will also become a problem for the user.
Again, this is something you still need someone to do for the microservice. None of these things are automatically solved by microservices. There are all kinds of automation tools for these things, but they work the same whether you use microservices or not.