[roberthahn]

I find people’s reactions to microservices to be fascinating. I have always looked at them with the same framing as Unix userland tools - many small, focused apps that do something really well, coupled with a super generic IPC mechanism - in Unix’s case, using pipes or message queues.

But Unix isn’t all small tools. We have servers for the heavy work- like databases.

The challenge then becomes; how do you design that IPC mechanism? Maybe it exists! I don’t know the answer yet. But it’s something I think about a lot and I haven’t seen compelling evidence for “microservices are always bad, no exceptions”

[cjfd]

Well, pipes are very nice and useful for small processing tasks. "I want to know how often the word 'Parameter' occurs in the source files inside this repository." That is great! pipes are your friend. They are the fastest way known to mankind to solve this problem. But they are also fragile. You may not have thought about the fact that the word NoParameter also occurs in the code base and you did not want to count that. Now, when writing something big and complicated pipes simply cannot keep up. Nobody wants a browser that is actually 100 small executables that communicate over pipes. It will be horrible. The IPC mechanism that you are looking for and that can actually handle what is needed for a browser is called 'function call' and it was already quite popular when C was introduced....

The interaction mechanisms between services, e.g. REST calls, is somewhere in between pipes and function calls. They are a bit more reliable than pipes and less reliable than function calls. They can be used for more complicated task than what pipes are used for but should not be used for task that are so complicated that they need function calls.