[erlang-questions] Separating Functionality

[Fred Hebert]

On 08/29, Code Wiget wrote:
>Hi everyone,
>
>With many programming languages, it is easy to think of ways to separate projects into distinct micro services. With Erlang, I'm having trouble deciding on how to spread out functionality. Because the Erlang VM can run multiple different fully independent applications, it seems tedious to spin up 5 different Erlang VM’s to do different things when it could all be accomplished on one.
>
>At the same time, as you scale, you probably want to separate functionality…
>
>So, do you have a rule of thumb or rules by which you decide on how to separate functionalities into modules vs applications vs entire releases?
>

My rule of thumb is always: How do I want this to fail?

Should the apps be independent from each other? Is one of them worth 
running without the other? If they can't live without each other then 
they're probably worth keeping on the same node.

Do they communicate heavily with each other?

The cost of talking over the network is higher than communicating over 
the loopback interface, which is higher than message passing. This can 
impact decisions.

Is one of the components unreliable?

If you got code talking to C or C++ programs that you don't necessarily 
trust, or that the code itself is kind of risky, isolating it entirely 
will allow to crash the whole VM of one app without hurting the others

What's their scaling factor?

If you have a stateless component serving lots of traffic for cheap 
(such as a web front-end), splitting it from stateful parts that must be 
treated more carefully may make sense; even put them on different 
machines if you must.