4 ms·

We run a lot of production Elixir apps at work, but we deploy them all in Docker containers on AWS basically. The whole live-upgrade erlang philosophy has alway

We run a lot of production Elixir apps at work, but we deploy them all in Docker containers on AWS basically. The whole live-upgrade erlang philosophy has always been one I've been curious about and interested in, but also a little skeptical of. It's funny to me that erlang (and Elixir) are so dogmatically immutable / no shared state "in the small" at the module and function level, but apparently not "in the large", at the system level. Whereas you tend to see the reverse with deploying most other languages.

toast0 6y ago
Erlang language level immutability is a means to an end, it makes the runtime (especially garbage collection) simpler than a system with mutable state where you can have references to newer and older data. At the systems level, immutability makes operating the system much harder. Especially when you consider Ericcson's basic design requirement of a telephone switch with a redundant pair of control computers; it's safer to deploy changes by making a temporary change to the live system than a permanent change to the backup system and switching over. In case of a bad deploy, you can live reload the old version on the live system, or if that's not possible, promote the backup system and restart the primary back to the known good state. If all goes well though, there's no period of reduced redundancy. In a restart to deploy situation, every deploy has a period with loss of redundancy, as well as a primary/secondary switch, and you can't deploy to degraded systems where one of the redundant pair is not working pending repair (these switches would most likely be deployed to towards the end of the cycle to reduce risk)
elcritch 6y ago
A large part of the philosophy is controlling state. Immutability in the small helps control where state lives. It’s difficult to control (or understand) state spread across hundreds of little objects (e.g. most OO languages) and be able to modify a running system. OTP Supervision trees and GenServers are all about partitioning state and organizing it. It’s similar in many ways to micro services, but more advanced (as the article mentioned regarding OTP Supervision trees and k8s).

toast0 6y ago

Erlang language level immutability is a means to an end, it makes the runtime (especially garbage collection) simpler than a system with mutable state where you can have references to newer and older data. At the systems level, immutability makes operating the system much harder. Especially when you consider Ericcson's basic design requirement of a telephone switch with a redundant pair of control computers; it's safer to deploy changes by making a temporary change to the live system than a permanent change to the backup system and switching over. In case of a bad deploy, you can live reload the old version on the live system, or if that's not possible, promote the backup system and restart the primary back to the known good state. If all goes well though, there's no period of reduced redundancy. In a restart to deploy situation, every deploy has a period with loss of redundancy, as well as a primary/secondary switch, and you can't deploy to degraded systems where one of the redundant pair is not working pending repair (these switches would most likely be deployed to towards the end of the cycle to reduce risk)

elcritch 6y ago

A large part of the philosophy is controlling state. Immutability in the small helps control where state lives. It’s difficult to control (or understand) state spread across hundreds of little objects (e.g. most OO languages) and be able to modify a running system. OTP Supervision trees and GenServers are all about partitioning state and organizing it. It’s similar in many ways to micro services, but more advanced (as the article mentioned regarding OTP Supervision trees and k8s).