This has always been a beautiful draw of the BEAM ecosystem for me, but during my exploration of the space I found that most people were deploying BEAM applications the same way as any other, say, Rails app, and I couldn't find a "getting started" of sorts to deploy desitributed BEAM apps the way you describe. I'd be interested in resources like that, if you have any.

A few months ago I started a series of articles about Elixir, K8s and libcluser[0], but unfortunately I did not have time to continue it yet.

If you're using K8s, what I would suggest is:

  - create multiple releases of your Mix project[1] with specific OTP applications in each
  - one Docker container per release
  - one K8s Deployment per release
  - one headless K8s Service selecting the pods for all your deployments
  - use libcluster for automated cluster formation

Then, with node affinity/tolerations, you can control on which physical node you'll run it (if you want).

If you're not using K8s, you can use an Ansible playbook to deploy each distinct release on the target host, and you can use libcluster with a static cluster configuration. This will work the same.

[0] - https://medium.com/@david-delassus/elixir-and-kubernetes-a-l...

[1] - https://elixir-lang.org/getting-started/mix-otp/config-and-r...

I've worked at two companies using Elixir/Phoenix and both of them treated it exactly like a Rails app and there was no discernable BEAM-y ness about it other than how the library worked under the hood.

I asked the more senior Elixir devs if we should do something to take advantage of the platform and was met with shrugs.

Hehe. Technically cheating though, nothing in Erlang will ever be really a monolith. But it's a great solution for the space, it does require a bit of unlearning before you can be really productive with it.

"Also, there is the midpoint between monolith and micro service, and this is called Service Oriented Architecture (SOA), you could have:

  - a DAL (Data Abstraction Layer) service
  - a Business Logic service (talking to the DAL)
  - an API (talking to the Business Logic service)
  - a Frontend (talking to the API)"

For me what you describled is just a common monolith.

I've been developing for 8+ years and have seen this model at every company where I've worked. I really thought this was just the "standard" way that everybody used to develop. I've also worked on a couple of CQRS architectures but the "layering" is still very similar to what you described.

I'm curious now, how do other monolith architectures look like if not like this?

In a monolith they may be modules within a single application/binary instead of different services.

Nobody said a monolith can't be split in modules :)

IMHO, a well-written monolith is like a microservice architecture but without the network layer in between boundaries.

Warning: Compilation times suck for Elixir/Erlang. I'm frustrated almost daily when I make changes to my code and have to wait for 66 .ex files to compile after changing one single line of code in a heex template.

Why do the other files get recompiled? they should be recompiled only if there is change in them.

I have no idea. That's what I'm seeing when working with my project.

Literally add one character to one of my liveview modules:

    Rebuilding...
    Compiling 67 files (.ex)

It's worth your time to investigate this, it's fixable. Check out mix xref to investigate dependency chains between files in your mix project.

In the project I work on, it turned out a module `use`d by almost every controller included a function (totally unused, btw) which, through a little bit of indirection, caused a circular compile-time dependency between all of them. So any change to any controller caused hundreds of files to rebuild.

Never heard of xref. I'll take a look thanks!

Probably macros.

This was improved in a recent release. Did you try with the latest version?

Ha! Came here to say this but you beat me to it.

https://news.ycombinator.com/item?id=31328580