A microservice is very similar to running a library as a server.

Some key differences:

You generally can't horizontally scale two libraries in the same process independently of each other, but you also don't usually have to worry about library availability at runtime.

If you don't need to scale a particular dependency separately, and you can't do useful work if the dependency is unavailable, then it should probably be a library.

Perhaps someone can explain to me the motivation microservices when there still exists a lot of runway for scaling up without scaling out.

It depends, whether you are talking about common popular programming practices. In which case if a library can run as a separate service putting it into a separate process improves reliability, security and performance, as you can run it through a supervisor, limit its memory, cpu, monitor it, automatically restart it when it becomes unresponsive or dies not affecting as many users and not bringing down entire systems with it, update it when needed, more easily isolate and address performance issues, explicitly design and think about new trust boundaries that come with it, etc.

> You generally can't horizontally scale two libraries in the same process independently of each other, but you also don't usually have to worry about library availability at runtime.

Are there cases where you need to scale one library possible without the network (IO and latency) becoming the bottleneck? The way most microservices get used as RPC mechanisms you hit the network bottleneck very quickly.

Libraries that need to scale out faster than other ones tend to be CPU intensive (or RAM intensive, which tends to imply CPU intensive since you will be missing the cache a lot). Those sorts of tasks are rarely bound by network traffic, particularly when you are within a single data center, where latency is low and bandwidth is free.

Microservices can be used akin to language-independent libraries. You can implement some ML functionality atop Python's marvelous scikit-learn, deploy it as a little service with an HTTP endpoint, and easily call it from an existing Node or PHP code base. That's easier and more effective than forcing unification to one language ecosystem.

Good point that they're language independent. I hadn't thought of that advantage.

Language independence comes with a trade off though.

You either have to repeat yourself by implementing your data models and validation routines in all the languages your service consumers might use, or instrument some language agnostic way to specify your data models and possibly generate code for them and their validation routines/client libraries, for a myriad of languages.

At that point, your basically reinventing something akin to sql and/or database schemas and constraints without ACID guarantees. You can deploy something like apache thrift or google's protocol buffers, and maybe throw in some swagger.io (which are all great things). But they are yet more layers, that for many levels of scale, increases complexity, rather than reduce it.

Or you can just trust all the services to never have bugs or breaking changes for consumer applications...

Still dependent on some sort of communication protocol.

The web is a universal standard, not sure how you can get more generic than that. I mean, you can't.

Bytes are a universal standard.

Big-Endian or Little-Endian?

oh you... you know what i mean, you have to have some standard way to talk. Bytes are tooooo generic. you don't want to be that guy at the party that is always saying but.... but you are technically correct :)

Yah I get confused when to apply when at times. If I had to distill it down to when I think its a gain: 1. You need some networked thing to be setup no matter what, 2. It is a pain to keep doing over and over from scratch or one-off even with a library 3. Its just super quick and easy to add one more config set and you're done. 4. THE MOST IMPORTANT ONE... drumroll, you get a subscription payment for it per customer!!! slightly evil but nice to be paid monthly for it. It may be slightly less evil though if you are charging the client less overall than going the other options.