[erlang-questions] Erlang and Docker

[zxq9]

On 2015年11月22日 日曜日 07:45:42 Tristan Sloughter wrote:
> I have to say that I partially agree with those here pointing out the
> use of a target system providing you with many similar benefits to the
> use of a docker image. And I'm no docker fan, but the argument that a
> release is basically a container is simply false and scrubs away all the
> useful purposes of a container, jail, zone, etc.
> 
> A release is not a replacement for the cases you need a cgroup, jail or
> zone. But if the only reason you think you need such a thing is to start
> an Erlang node you may be engaging in overkill that will be technical
> debt.

Absolutely.

To expand the discussion a bit further though...

I've seen more folks blindly employ segregation facilities like cgoups
and especially jails because they thought they were primary security
features than realizing they are environmental segregations. "Scrubs
away all the useful purposes of a container, jail, zone, etc." I don't
find these particularly useful compared to simple virtualization -- and
virtualization itself is also not a primary security feature. (The term
"jail" was poorly chosen, in retrospect.)

With this in mind, I tend to view things rather more black and white: VMs
or local execution -- pretty much anything else is indeed technical debt.
But its the cool-feeling kind of technical debt that comes complete with
a bodyguard of totally kickass websites, buzzwords and ready-made
consultant army. (otoh, if you have to pay a fee per OS image or committed
core, then VMs can easily move you from "technical" to "finanical" debt)

I'm not saying these things don't work -- they do. But they have never
actually made deployment or maintenance any easier over the long term --
instead merely move the complexity involved in those tasks elsewhere for
a while. I wind up having to learn and *maintain* several new skills on
top of >gasp< already having to deploy in VMs anyway. Splitting system
components up as network services, though -- that actually *has* been a
big win, and I don't really care how those are deployed, what language
they are written in, or how they are hosted.

Containerization, of any form, encourages coupling at the grand
architecture level because it hides the long-term pain of coupling
tradeoffs very well. That is really what I'm most concerned about.

A well written service should be deployable to any target platform in a
simple way. We just skip this step when we aren't writing client-side
software -- but its not so hard to get right if we start out with this
in mind instead of just barely getting a development environment working
and then letting devops make that the blueprint for production. Here I
am certainly not talking just about Erlang-only services -- it is a broad
problem.

I'm not particularly fond of Erlang releases for *everything* -- I think
it is very often overkill and understanding what a release even is seems
to repel a lot of folks who like the language and runtime but don't grok
that aspect of the environment (after all, most Erlang code written today
is not targetting embedded phone switches with constrained resources and
limited underlying system facilities), but it *does* simplify deployment
dramatically (once you come to terms with the technical debt involved in
getting Erlang releases to work right...), and ease-of-deployment seems
to be the focus of most chatter about containerization.

-Craig