[aidenn0]

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.

[zzzcpan]

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.

[flukus]

> 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.

[aidenn0]

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.