Ask HN: What is your opinion on multi-process microservices?

I maintain an open source microframework for building and running realtime apps/services. It is designed to run on multiple processes out of the box (That is; it spawns and manages multiple processes internally - So it handles worker failures and respawns child processes for you) - Basically it handles the full responsibility for running a particular realtime/messaging microservice across multiple CPU cores (including the process management/coordination aspect of it). Many database engines have also taken the integrated multi-process approach.

There are a lot of different trends unfolding at the moment and I need advice on what direction to take for my project (might be looking to Dockerize it at some point).

I noticed a slight trend towards single-process microservices (this is particularly true in the Node.js community) - In this case, typically, services are managed independently using a process manager (e.g. PM2) - The process manager takes care of launching and restarting individual processes and allows you to make use of multiple CPU cores that way.

The challenge with this approach is that sometimes there are cases when you want two or more tightly-related processes to always run together (and launch in a particular order for example) and they have to share information like passwords/secret keys, or each process needs to know about how many other processes are running (in order to interact with each other - Possibly using a consistent hashing strategy).

There are tools like docker-compose which aim to handle this coordination aspect but it's not yet clear whether or not this will suffice to completely remove the need for fully integrated, multi-process microservice solutions.

With all this said, what is your position on integrated muti-process microservices? Should a microservice be responsible for its own scalability across multiple CPU cores or should that be delegated to a process manager?