Just linking processes together is not enough to build a cluster. How do you allocate the physical resources, deal with network splits, package and deploy new code, monitor... There's a whole layer that's missing there that would surely be nice to have. The OTP framework could even be used to sandbox in LXC and start other type of applications.
Lots of that is a scoosh in Erlang, deploy, monitor, manage clusters. You have monitoring, cross-machine process linking, remote code loading all based on network transparency....
Network splits and many other multi machine distributed computing problems aren't addressed well by Erlang because it was designed mostly for distributed computing within a single machine (that might have several CPUs and/or blades).
Erlang will work spectacularly well in those scenarios and is explicitly aimed at them, definitely not just for 'distributed computing within a single machine' (which is nonsense anyway). The reason why it can't deal well with network splits is better explained by internalizing this:
If I remember correctly, Erlang was designed for fault-tolerant telephone switches and there were always two of them (the switches) in one box, because the system had to cope with even hardware failures.
So Erlang is pretty much designed to deal with systems distributed on different machines, it's nice behaviour on modern multicore machines is just a byproduct of that.
Comments
Just linking processes together is not enough to build a cluster. How do you allocate the physical resources, deal with network splits, package and deploy new code, monitor... There's a whole layer that's missing there that would surely be nice to have. The OTP framework could even be used to sandbox in LXC and start other type of applications.
Lots of that is a scoosh in Erlang, deploy, monitor, manage clusters. You have monitoring, cross-machine process linking, remote code loading all based on network transparency....
That is what LING (formerly erlang-on-xen) is here for: http://erlangonxen.org
That doesnt really solve all those problems in itself does it?
It's pretty cool but I don't think that it's open-source.
It seems to have an open-source, copyleft, non-GPL license [1].
[1] https://github.com/cloudozer/ling/blob/master/LICENSE
why, you can grab the source on github: https://github.com/cloudozer/ling
Network splits and many other multi machine distributed computing problems aren't addressed well by Erlang because it was designed mostly for distributed computing within a single machine (that might have several CPUs and/or blades).
Erlang will work spectacularly well in those scenarios and is explicitly aimed at them, definitely not just for 'distributed computing within a single machine' (which is nonsense anyway). The reason why it can't deal well with network splits is better explained by internalizing this:
http://en.wikipedia.org/wiki/CAP_theorem
If I remember correctly, Erlang was designed for fault-tolerant telephone switches and there were always two of them (the switches) in one box, because the system had to cope with even hardware failures.
So Erlang is pretty much designed to deal with systems distributed on different machines, it's nice behaviour on modern multicore machines is just a byproduct of that.