[erlang-questions] Freedom Box and Erlang

Tue Jun 21 04:36:06 CEST 2011

On 06/20/2011 02:42 PM, Tim Watson wrote:
> On 20 June 2011 20:04, Michael Truog <mjtruog@REDACTED> wrote:
>> True.  CloudFoundry exists and is open source.  However, it is Ruby based so it is unable to scale like an Erlang system (like CloudI).  CloudFoundry is control by VMware, which is an organization, and they are using the Apache License 2.0.  CloudI is independent and uses a BSD license, so it can be reused anywhere.
> First up, I'm definitely not knocking CloudI here - I think it looks
> awesome. CloudFoundry is owned and developed by an organisation, but
> so are plenty of other things (riak, rabbitmq, etc) so that doesn't
> automatically mean lock-in. I mean Erlang/OTP is controlled by
> Ericsson right, and by the same measure CloudI is controlled by
> Michael Truog. The Apache License 2.0 is more restrictive than the BSD
> type license you've chosen for CloudI - and good on you for making it
> as open as possible - but I can still use and adapt stuff based on the
> Apache license for commercial or similarly licensed open source
> projects.
I agree.  Often times organizations make strategic decisions to include and exclude support for various types of software, which either benefits their partners/divisions or harms their competition.  Having an open source project that is independent means that it is able to pursue a path to the best combination of technology based on what the community thinks (though limited by time/money).  That way there should be no major influence based on "competitive advantage" decisions that are commonly made by any commercial organization.

I am not a lawyer and I am not giving legal advise.  However, I think it is more likely that BSD licensed software is reused and then sold in a commercial product, when compared with Apache licensed software.  The main difference between the licenses is over patent ownership (BSD is assumed, Apache is explicit), so the differences might be very negligible when you consider the content in each license.  Part of the bias for support of the BSD license may be because of its simplicity.
> Secondly, I agree that Erlang/OTP is a gift from the Old Gods of the
> North when it comes to fault tolerance and so on, but just because
> app-1 is written in Erlang and app-2 is written in Ruby, doesn't
> automatically mean that one will scale better than another. Both these
> cloud frameworks are based (at least in part) on services running as
> native OS processes - admittedly you support native Erlang
> services/jobs - and the other comparative technologies are really
> around routing and distribution. Here both frameworks are relying on
> the same kind of underlying TCP stack that takes advantage of
> non-blocking socket I/O - distributed Erlang using the inet
> infrastructure running on a beam emulator compiled with --enable-poll
> or whatever, versus CloudFoundry which runs on event-machine, a
> framework a la libevent. Distributed Erlang is known to have
> limitations of its own, that wouldn't necessarily apply to a very
> large grid built on some other distribution protocol - riak for
> example uses a custom protocol, as does Scalaris I think and probably
> quite a few others. The fault tolerance that is built in for you
> (because you're running on top of OTP) though, is admittedly a big
> selling point.
I am judging based on the VMs involved and their known scalability limitations.  Having libevent in a project does not make it scalable.  There are many projects that use libevent that do not scale judging based on loadtest results.  Also, libevent usage, when done incorrectly, makes the system fail prematurely, so it should not be seen as a panacea for scalability.  The approach to scalability is achievable in many ways, but the complexity of the result is a concern since that controls how testable the system is.  Looking at the Erlang VM scale (with epoll/kqueue, the "+K true" (kernel-poll) erl command line argument) using the inet infrastructure and light-weight processes (one Erlang process per socket), 10K+ scalability is easily achievable with simple code that is usable as beginner examples.  When you compare that to other solutions where loadtests rarely hit 10K (usually HTTP servers and different configurations), with code that is actively developed for any length of
time, I think Erlang is clearly the winner.

When you consider scalability across separate machines, that is a separate concern.  The distributed Erlang fully connected network topology is an advantage for creating Erlang systems.  However, when the node count needs to be increased beyond 100 (roughly) it is necessary to have a tree network topology to keep things fault-tolerant.  ZeroMQ integration configuration could be used within CloudI to avoid the distributed Erlang node limitation.
> Don't get me wrong - I'm not asserting any amazing properties about
> ruby, nor am I trying to criticise your work. It's just that you're
> clearly very smart (because you wrote a complex beast like CloudI) so
> your peers (and even underlings like me) need to hold you to account
> for intellectual honesty. Saying "it is Ruby based so it is unable to
> scale..." is FUD unless you qualify it in more detail. Most people on
> this list would be inclined to think you're on to something, but this
> is not a black and white area. I'm pretty sure that services such as
> Github and Heroku are very scalable, and they use both Ruby and Erlang
> (and probably only Odin knows what else) for various tasks.
Sorry, not trying to start a language flame-war.  I like Ruby and enjoy how succinct it is.  I just think that it is important to use the right tool for the right job.  Github and Heroku have both talked publicly about how Erlang has helped them scale their back-end systems.  So, I think most companies are becoming aware that a Ruby front-end can scale with an Erlang back-end.  However, I don't see anything within CloudFoundry that can provide scalability like Erlang.

Michael

>> On 06/20/2011 11:34 AM, Tim Watson wrote:
>>> There is also http://www.cloudfoundry.org, which is sponsored by
>>> vmware and has a commercial offering too (at cloudfoundry.com) but is
>>> open source - https://github.com/cloudfoundry.
>>>
>>> On 20 June 2011 15:55, Evans, Matthew <mevans@REDACTED> wrote:
>>>> Seems like you have an interesting project with cloudi.
>>>>
>>>> Matt
>>>>
>>>> -----Original Message-----
>>>> From: Michael Truog [mailto:mjtruog@REDACTED]
>>>> Sent: Saturday, June 18, 2011 3:15 PM
>>>> To: erlang-questions@REDACTED
>>>> Cc: Evans, Matthew
>>>> Subject: Re: [erlang-questions] Freedom Box and Erlang
>>>>
>>>> To have an Erlang cloud that doesn't depend on an organization, there is CloudI (http://cloudi.org) .  So it could be used for running applications on a distributed mesh.  There is ZeroMQ integration that could provide communication between the FreedomBoxes.  CloudI currently lacks a pretty UI for managing the configuration and will be going through more testing, so those are current barriers.
>>>>
>>>> On 06/18/2011 10:54 AM, Evans, Matthew wrote:
>>>>> Hi,
>>>>>
>>>>> I've recently been reading about Freedom box (see: http://wiki.debian.org/FreedomBox and http://freedomboxfoundation.org/).
>>>>>
>>>>> In a nutshell, directly from their website:
>>>>>
>>>>> "Smart devices whose engineered purpose is to work together to facilitate free communication among people, safely and securely, beyond the ambition of the strongest power to penetrate, they can make freedom of thought and information a permanent, ineradicable feature of the net that holds our souls."
>>>>>
>>>>> "We live in a world where our use of the network is mediated by organizations that often do not have our best interests at heart. By building software that does not rely on a central service, we can regain control and privacy. By keeping our data in our homes, we gain useful legal protections over it. By giving back power to the users over their networks and machines, we are returning the Internet to its intended peer-to-peer architecture. "
>>>>>
>>>>> I'm not a member of the organization, but it seems to me that the distributed nature of Erlang could offer awesome possibilities to work around certain technical difficulties. I could, for example, envisage a mesh of Erlang nodes connected together providing various distributed services where no individual is in overall control. Or you could provide services (Erlang processes/application) owned and managed by someone from a country with poor human rights that is in fact running on an Erlang node on a country with better human rights (a chat service for example). I'm not talking about "cloud" services here (that some organization ultimately owns), but running applications on a mesh of privately owned "Freedom boxes" that host Erlang VMs. The beauty of Erlang is that it's innate ability to distribute code, processes and applications in such a simple and seamless manner could provide very powerful tools for the organization.
>>>>>
>>>>> Any comments and thoughts on this?
>>>>>
>>>>> Matt
>>>>> _______________________________________________
>>>>> erlang-questions mailing list
>>>>> erlang-questions@REDACTED
>>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>>
>>>> _______________________________________________
>>>> erlang-questions mailing list
>>>> erlang-questions@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-questions
>>>>
>>
>>