(1) Distributed Erlang was primarily intended for physically colocated hardware that was networked in a “secure” manner (e.g. isolated from outside interference; think each node running on a separate board communicating through a common backplane).
(2) The following is a mere rationalization of this experience.
-
The cumulative code deployed to a single node aggregates to a single system. That system could simply be a sub-system to a larger whole but running on a single Erlang runtime acts as a single autonomous unit no matter how many processes exist on the inside.
-
For the purposes of fault tolerance (provided (1) is satisfied) distributed Erlang (i.e. process communication between nodes) makes sense because the systems are identical. There is no issue with implementation coupling because the systems are identical. The nature of the communication traffic is closer to intra-system rather than inter-system communication.
-
If two systems operating on two separate nodes implement different capabilities then more mainstream communication protocols should be preferred. Using distributed Erlang leads to implementation coupling because now all the collaborating systems have to be either implemented as BEAM systems or at least have to communicate through proxy technologies such as C Nodes, jinterface, or Pyrlang. Also more mainstream protocols may make it easier to use more common network monitoring (or perhaps even governance) tools.
Another consideration is the protocol design between systems. Ideally messages between systems should have a coarser granularity and occur much less frequently than messages inside the system. From that point of view it makes sense to move inter-system communication to an altogether different network protocol rather than using inter-process messaging. In the IoT space MQTT seems to be the preferred protocol (Visualizing Home Automation with GRiSP).
I would imagine that in the IoT space Erlang/Elixir isn’t that impacted by the Docker/K8s prejudice. However other languages and runtimes are available in that domain. The issue is that often tools that optimize for a low barrier of entry and fast first iteration delivery and deployment are adopted over tools that strive for all around (long-term) quality. I’ve already mentioned PHP and I think Python for Machine Learning fits there as well. I suspect that Python and JavaScript are popular with the “easy to get started” IoT crowd - despite of the technical short comings that may impose on the resulting solutions.
