

Bringing Erlang's Fault-Tolerance to Polyglot Development - bbeneschott
http://www.toptal.com/erlang/a-cloud-at-the-lowest-level-built-in-erlang

======
RyanZAG

      Basically, building real-time fault-tolerance support on top
      of the JVM is by definition impossible, because the JVM
      itself is not fault-tolerant.
    

This isn't strictly correct. The article talks about the big difference
between the JVM and Erlang being a shared heap vs multiple heaps, but really,
it just comes down to coding. There is nothing stopping you from using message
passing and immutability in the JVM, and many libraries (eg Scala Actors) do
exactly this.

So it's definitely not _impossible_ to build fault tolerance on the JVM.

Also the diagram showing Erlang acting on any number of CPUs while Java is
somehow limited to 2 CPUs is simply a marketing lie and is very unnecessary.
The JVM can scale happily to any number of CPUs, as it piggy backs off native
OS threads, which in linux/windows both scale to any number of CPUs.

~~~
okeuday
You can try to have fault-tolerance in the JVM, but not real-time fault-
tolerance, and there is a difference. The goal is to have decent performance
while being fault-tolerant. The JVM garbage collection prevents real-time
fault-tolerance when using an Actor model within the JVM.

~~~
RyanZAG
Can you explain this concept in a bit more detail? There is nothing I can find
to back this up anywhere, and the idea seems very strange to me as I've never
heard of it before. A quick Google search on the topic seems to show a number
of papers detailing real time fault tolerance on Java.[1]

At any rate, as far as I can tell CloudI is mainly intended for network and
web systems, which are not going to be real time when running on Linux/Windows
in any event. (network buffers, etc)

[1]

[http://dl.acm.org/citation.cfm?id=1404893](http://dl.acm.org/citation.cfm?id=1404893)

[https://weblogs.java.net/blog/editor/archive/2013/03/18/jona...](https://weblogs.java.net/blog/editor/archive/2013/03/18/jonas-
bon%C3%A9r-jfokus-2013-building-scalable-highly-concurrent-fault-tolerant-
systems-lessons-learne)

[http://books.google.co.za/books?id=BroUpHAZThwC&pg=PA470&lpg...](http://books.google.co.za/books?id=BroUpHAZThwC&pg=PA470&lpg=PA470&dq=java+real+time+fault+tolerant+systems&source=bl&ots=tSzIVpUOo4&sig=OmguyZgN3lxwppMu9Kk7Qtm-
iyg&hl=en&sa=X&ei=dIvEUduLHMnF7AbahYGACA&ved=0CDQQ6AEwADgK#v=onepage&q=java%20real%20time%20fault%20tolerant%20systems&f=false)

~~~
okeuday
CloudI and Erlang underneath are focused on soft real-time. For hard real-time
(embedded) you need tighter integration with hardware. While it is true that
people attempt to pursue (soft) real-time fault-tolerance on the JVM, the
point in the CloudI article is that the pursuit does not achieve fault-
tolerance which can be considered real-time, simply due to the JVM garbage
collection which must interrupt real-time processing of an Actor model. This
problem isn't often discussed, but is a simple way of showing the problems
with fault-tolerance on the JVM. Without the JVM supporting fault-tolerance,
the effort to have decent (real-time) fault-tolerance would be similar to
creating a new VM. Since creating a VM is difficult to do properly, and
testing is required after its completion, it makes much more sense to use the
Erlang VM since it has native real-time fault-tolerance that is already used
in commercial products.

------
nnq
Simple question: how could I _migrate away_ from this platform if at one point
or another I would get unsatisfied with either the platform or would need this
on my own servers? Is there an open-source platform technology? Is this also
available as a plain ol' software-as-a-product that I could use on my servers?

~~~
okeuday
CloudI is under an open source software license, the BSD license, which is the
most permissive of the open source licenses. So you can use CloudI in any
product you want, using it how you want, on whatever servers you choose. The
license just protects the CloudI source code developers from liability.

~~~
nnq
cool. you should write somewhere visible that the underlying technology is os
bsd, it's a strong point for someone choosing to use it or not!

------
endlessvoid94
This seems like a really interesting approach. I've often wondered what it
would be like to live in a world where almost everything could be wrapped in a
transaction, and it seems like Cloudl _sort of_ goes in this direction.

~~~
okeuday
In CloudI, each service request is a transaction to be processed (with a UUID
that is unique for all service requests among the connected CloudI nodes).
Filesystem storage of transactions isn't a goal here, since transactions are
expected to die when errors occur within services
([http://en.wikipedia.org/wiki/Transaction_processing_system](http://en.wikipedia.org/wiki/Transaction_processing_system)).
Instead, database usage through CloudI services (or within a CloudI service)
provides persistent storage.

