Where does Elixir/erlang fit into the microservices approach?

The question asks how Elixir and Erlang fit with Docker and microservices, especially around dev-prod parity, immutable containers, hot code upgrades, and release strategies like blue/green or canary deployments. It also asks whether Elixir is best used as ordinary microservices or as part of a more integrated OTP system.

Reading notes

#

• The questioner says Elixir encourages multiple decoupled applications and hot code upgrades, but wonders how that fits with Docker’s immutability and with deployment patterns such as blue/green and canary releases.
• The accepted answer says Elixir and Erlang are built for distributed systems, and that this is already visible in applications, processes, supervision trees, and runtime tooling.
• It says applications are started and stopped as units, have a unified directory structure and configuration API, and include the supervision tree that contains processes and state.
• It says this structure gives developers a clearer way to reason about startup, state, and crash behavior in production.
• It says Erlang/Elixir already provide communication and serialization mechanisms for distributed nodes, so machines can talk by name and shared secret without needing HTTP and JSON.
• It says microservices are not the main issue at that point, because the system is already made of isolated processes grouped into applications.
• It says applications can be deployed together or split across nodes, and that the same design also allows running them in one node if microservices complexity is not wanted immediately.
• The follow-up comments say Docker is useful for node deployment, and that blue/green deployments depend on protocol, state, and routing choices such as distributed Erlang, Consul, or HAProxy.