1. 20

  2. 3

    But why would you need Docker to deploy Erlang? OTP releases are better than Docker containers.

    1. 1

      I suggest reading the Releases and Docker chapters, or at least the introductions. They are not really comparable and I try to explain what a container provides when bundling a release.

      1. 3

        I know what a container provides, I’ve been running jails since before Linux had any notion of containers.

        BEAM does not need cgroups or other types of process isolation. And when you’re deploying with docker, you can’t do hot code upgrades because to upgrade the container you’ll have to destroy the container and deploy a new one, right? So… what do you benefit from except tooling that is far more complicated than rsync and now you have to rely on infrastructure in front of your services for load balancing/failover every time you upgrade vs only when an actual outage occurs.

        edit: maybe I’m being fed some incorrect information as well, so I’m curious to hear what you have to say about this

        1. 3

          I hope it is well covered in the chapters and would be interested to know if it isn’t so I can update them.

          Briefly, release upgrades are rare. They should only be used when necessary because of the complexity which often comes with no actual benefit.

          Your point about rsync and load balancers in front of a service is unrelated to BEAM. This is true for any language. Cases where you only have 1 node, which you fully control, isn’t what is being covered here. But BEAM isn’t different when it comes to horizontal scaling and the need for infrastructure in front and needing infrastructure for release management. BEAM projects work just as well with whatever infrastructure the organization is already using for deployment, whether it is rsync to nodes or orchestrating containers.

          1. 1

            Briefly, release upgrades are rare.

            Is a “release upgrade” alternatively called “hot code reloading”?

            1. 2

              “release upgrade” (http://erlang.org/doc/design_principles/release_handling.html#release-upgrade-file) is a structured form of “hot code loading”. Since “hot code loading” could refer to also what people do during development to reload modules in the shell after its been recompiled.

              I have worked on one system that did production upgrades outside of release upgrades, by basically doing what a relup would do itself but doing so manually in a script, but it is rarer than even release upgrades.

              1. 1

                Thanks for the clarification!