[erlang-questions] Erlang and Docker

[zxq9]

On 2015年11月22日 日曜日 11:19:45 Stefan Hellkvist wrote:
> > 21 nov. 2015 kl. 21:52 skrev Felix Gallo <felixgallo@REDACTED>:
> > Erlang is already like a miniaturized operating system implementing well-scheduled lightweight microservices, and releases (http://www.erlang.org/doc/design_principles/release_structure.html) are already a redistributable, self-contained, minimizable unit of deployment that can be monitored, inspected and logged using standard unix workflow.
> > 
> > In my opinion, the cost-benefit of using docker is highly questionable even in its optimal use case, where the dev team is composed entirely of inexperienced front end javascript developers trying to deploy monolithic microservices and pretending they're being lightweight.  Maybe there's a case to be made for tooling which takes languages with terrible manageability and hides them behind something, but it's not at all clear that docker is the answer to that or any other question.  It makes a negative amount of sense to layer the highly ceremonial, unperformant, problem-multiplying docker abstraction on top of an actually light, already existing microservices architecture, and I wouldn't wish ownership of the resulting mutant chimera on my worst enemy.  But again -- my personal opinion.
> > 
> > F.
> 
> Perhaps this is true for homogeneous systems such as systems only built with Erlang components. Many systems are however hybrid systems with different component types and a container architecture (such as docker) could help in making things more homogeneous.

[BEGIN RANT: Docker is not a best practice]

Then those systems have not either been appropriately bundled (lots of releases drop other language bundles in priv/) or abstracted across the network as separate services (this is SO FREAKING NOT HARD TO DO AND MAKES LIFE EASIER FOREVER WHY ISN'T THIS THE DEFAULT MODE OF THOUGHT WTF AHHHHHHH!). The reason I've grown skeptical of both docker and "fire and forget" virtualization is that I generally see containerization as a way for devops to barely cobble an environment together in a rush before some deadline, slap a label like "WorkingBaseSystem X" on it -- and consider their job with that particular platform as complete, forever.

Which means...

- It is never maintained (until something like heartbleed... dhoh!).
- How it was made to work in the first place is lightly/never documented.
- The interactions among components are not documented.
- Interfaces are not defined.
- Sloppy hacks are very hard to discover.
- Updating the system is a *terrifying* prospect.
- Reviewing the old code to document structure/flow becomes archaeology.

They become security landmines until the end of time, and most management teams seem to think "its not broke; don't fix it", but are confused as to why their devs becomes paralyzed the moment some new feature or bugfix is required in the old system -- so instead begin replicating functionality buried in the old system.

In the case where the containerized system represents the core business, sure, that is maintained and updated -- and in those cases containerization isn't really much of an asset because its not competing with other configurations for primacy over settings. In the case where the containerized system is not the core business containerization encourages the horrible trends I wrote about above. In the bad case this means that there will probably never *be* another major version release of whatever system lives in the "hybrid system with different component types and a container architecture" because nobody will ever be able to figure either what that system does inside, or never figure out how to resolve the christmas-lights-tangle of settings and version choices that has been containerized.

If the system is well maintained, these things are obvious and docker isn't buying you much; if the system is not well maintained docker is just covering up the accumulating stench by dousing it in fabreeze and wrapping it in a blanket really tight.

With regard specifically to Erlang, a release basically *is* a container, though placing that again within a VM/docker/container/whatever doesn't really hurt anything -- its just not as big a win, and it certainly does make things more complex for no reason (now you have to make two releases, one nested within the other).

"But nobody has time to [do X]"
  when X :: document the mysterious system
          : define interfaces
          : figure out what versions of what work with what else
          : update component subsystems
          : whatever other time-consuming task
Then you
 - Make time
 - Appreciate that you are going to swim in mud until you make enough
   money to break into open water
 - Start looking for another job before your current company implodes

Theoretically maybe docker has some really super great benefits for Erlang... but in practice I've generally just seen it (and not just docker, again, all forms of containerization) become an excuse for (and later evolve into a justification of) profoundly sloppy operational practices. For some reason I see this a bit less with VM-based solutions than docker (but seen it there, too).

"Gee, Craig, why all the vinegar?" you may ask.

Because the difference between a heterogeneous/homogeneous environment should not be a major design issue, which implies that methods to deal with different components as totally separate, totally abstracted entities should be a fundamental part of any large system design (this method is usually called "sockets", and they don't all have to be HTTP... >gasp!<). You shouldn't be running gleefully along and just suddenly realize you've built not just a monolithic code base, but a Jenga game of the supporting system that it runs on as well. This is a solution to a problem that shouldn't exist, and the way to do better things is not to just sweep it under the rug and consider this "a best practice", but rather regard the need for this form of deployment as a sign that you've screwed up and painted yourself into a corner. If you find yourself having to use docker, especially for an Erlang-based system, you should think "thank goodness we can bundle this awful mess up for now until we get our fundamental problems sorted out".
[END RANT: DINABP]

-Craig