[cdoxsey]

I think this has two major downsides:

1. Setting up containers and the communication between them is really complex - it also only makes sense for a deployed, long-running, server process. 2. Communication between containers is very expensive. You're never going to beat an in-process pointer to shared memory.

Web workers would make a lot more sense for most javascript programs.

[bertolo1988]

1 - How is REST complex?

2 - That is only true if the your bottleneck is on communication somehow. Usually it is not.

And a huge advantage: You will write stateless and easy to scale apps that do not care how the machine resources are being handled.

[cdoxsey]

You need to run multiple applications side-by-side and they need to be able to talk to each other. With containers that means figuring out the network layer and service discovery.

It also means accounting for each system failing in your own app, retries with exponential backoff, timeouts, logging errors, circuit breakers, plus all the exotic ways a network layer can fail - if your RPC protocol has arbitrary limits (message size, timeouts, etc)

You will probably want to use kubernetes with istio, not raw docker. All very do-able, but definitely not simple.

I agree that services make sense, but there's a level between single-threaded and micro-services where having concurrency within your application is useful.