Should Erlang systems (or anything running on the BEAM VM) be monolithic, i.e. everything running in the same distributed application, or should they be split into multiple microservices like any python/go/c++ shop would do?
Since each process in Erlang has its own memory space, it seems like they behave like microservices internally, and thus, a single Erlang application should be enough, but maybe there's something I've overlooked?
Please note that there is no concept of namespace or process isolation within Erlang VM. You can have only one module with a specific name, so you if you try to run too many different applications eventually you may end up with conflicting names.
Having said that, there is nothing preventing an Erlang VM from taking all the resources available and growing as big as necessary. I have worked with systems running a single VM on 32 CPU systems with 100 GB of memory. The BEAM simply launches one scheduler per CPU and distributes the Erlang processes across all available resources.
It's more a matter of anticipated load, development scalability, and the design of the overall architecture. Some points to consider:
Each node is updated as a unit - if something goes wrong the single VM crashes and needs to be restarted. Imagine that the node running on 32 CPUs, taking 100 GB of memory, and handling hundreds of thousands of users at a time crashes during the software upgrade and starting it takes an hour because that's how long it takes to load the data from the DB to the memory. If that's your scenario you may want to decouple the node into multiple micro services that can be upgraded in isolation. However, if you have 10 nodes like that and the traffic is distributed among them then you may just take the route of least resistance.
Because of the lack of namespaces and process isolation from the development point of view it may be easier to maintain a common repository with all the applications (to avoid name clash) but create multiple Erlang releases, each one running a specific service using only a selection of applications available in that repository (micro service).
Testing is much easier if you have multiple micro services that can be tested in isolation where the other nodes are mocked than if you have a big multipurpose node doing everything and the kitchen sink.
Erlang is designed to be massively scalable. Erlang processes are lightweight; you can have millions of them if you want to. So each "microservice" to which you refer will most likely map to several Erlang instances.
It's probably more helpful to think of each microservice as a Module, not a Process. My suggestion would be to create a module for each microservice, and spin up an Erlang process for each incoming microservice request.
Further Reading
Erlang Modules
Erlang Processes
