I feel like there is a fundamental misunderstanding about how to think about systems within the Erlang/Elixir paradigm at play here, and it’s affecting the core design and thinking about how to structure your application(s) to resolve your problem.

A microservice is a program that is designed to have a small area of responsibility, and thus a small surface area when it comes to its API. It can be launched on the same or different hardware stacks as other microservices, but that is a deployment detail that can mostly be ignored.

A process, be it a GenServer or whatever, is a unit of concurrency within the Erlang/Elixir ecosystem. Schedulers allow processes to also be run in parallel, but even that is a result of the concurrent aspect of processes.

Trying to map these two concepts together, with a process equaling a microservice, is going to lead to problems as they are not the same. A microservice could easily be made up of thousands of running processes, or just one…well two if you count the application supervisor.

Similarly, attempting to do clever tricks with blocking rpc calls, or manually controlling the launch of Elixir applications on different connected nodes–while possible–is just increasing the possible configuration and debugging pain points of a running production system. I also just see it as a lot of added complexity that isn’t needed if you just design your solution differently.

If you aren’t going to make a true stand alone microservice (that communicates in a language agnostic protocol) and want to use the slick Elixir communications tools and interconnected nodes…why hang onto that concept at all and not just dive straight into solving the problem the Elixir/Erlang distributed way from the beginning?

This is definitely possible using only distributed erlang: Distributed Applications — Erlang System Documentation v27.1.2

Why do you prefer source code independence? There’s many benefits of keeping the source code to multiple parts of the entire application/company in the same code-base. Such as the ability to make updates to multiple parts of the system “atomically” (i.e. in one git commit). IIRC Google and Facebook actually just use one huge repository that has the code for all of the projects in the entire company.

Umbrella projects are a folder structure to develop related otp applications in a single fashion, mostly to resolve the issues of independent projects like version mismatches. If you’re after source code independence why not simply have multiple mix projects?

Sure, but that should be rather a matter of creating the correct kind of communication interface and deploying stuff onto your infrastructure in a way to let them talk to each other. Umbrella on the other hand is just a fancy word for “one folder for multiple apps”. At runtime there’s no difference between apps created as umbrella and apps created independently.

Also keep in mind, that by default erlang nodes connect in clusters automatically, where each node is connected to each other node in the cluster. Depending on the number of physical nodes you expect to be running on this might not be the best architecture.