[erlang-questions] Erlang and Docker

[Gokhan Boranalp]

Hi all,

We had several problems mostly because docker based containerized
solutions not perfectly fit to resource intensive Erlang apps. lxc and
nspawn[1] seems much more reliable to use.
We use Coreos, Fleet and Consul for Python apps but *not* for Erlang though.
We should have something isolated and having much control on CPU and
RAM as VM does but we should have quick deployment, OS with reduced
abilities etc. to manage SDLC.
Therefore, i would like to draw your attention of Unikernels[2]. I
believe the future will shine with these minimal kernels, small set of
needed drivers and a hypervisor which is only shaped for your
application.
As a good starting point, you can find a recipe to bake Erlang on
Rumprun if you like to.

[1] http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html
[2] https://en.wikipedia.org/wiki/Unikernel
[3] https://github.com/rumpkernel/rumprun-packages/tree/master/erlang



On Wed, Dec 2, 2015 at 10:43 AM, Ameretat Reith
<ameretat.reith@REDACTED> wrote:
>> Some day in the far future, we may reach a point where Erlang is the
>> only language we're running (or at least the only one on a particular
>> server) and then it might be attractive to un-containerize it. On the
>> other hand, maybe not. Adding another layer of virtualization in the
>> form of Docker has cost us very little so far.
>
> It happened to us.  We have provided -and still doing- network
> solutions written in C and executed in containers; at first we used
> Docker but after putting much energy in struggling over It's bugs for
> our high load environment, switched to very very more stable lxc.  I
> can summarize our reasons for using containers into two:
>
> 1. We didn't like our users -about 3K for each service- interrupt for
> an update.  So we would make another container, zero load to previous
> one and remove It when Its users gone.
>
> 2. Our softwares would not natively scale that much to use all cores
> in an efficient manner,  they won't scale linear with more powerful
> hardware.
>
> We made same software with Erlang an as we did we dropped using lxc
> to.  We write -sometime time consuming- relups and update while service
> is running.  We don't need to wait 1 day to all users of a lxc image go
> and It make very good sense.
>
> And about scalability, Erlang based software scales better than
> linear!  It's CPU usage per task drops after feeding more tasks to
> it and It's not slower than our legacy solutions.
>
> Ease of deployment not changed very much after using Erlang, we used
> DevOps tools -Canonical's Juju- to start container images which needed a
> well written script to build in ci server; now we just execute that
> shell scripts in host environment.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions



-- 
BR,
\|/ Kunthar