Can you share a bit about the deployment story. I haven't really been able to get a good view of the automation behind that. Granted, I have yet to develop anything actually deployable, but would love to hear some opinions about that.
So you get isolation (beam processes), decoupling (message passing) and resilience (supervisors) without having to deploy and maintain N different apps and the pain points that come with that (monitoring, discovery, integration testing, debugging, ...)
Our company has other systems, in other languages, and a pretty involved deployment process (docker+nomad) so our deploys are pretty specific to that. But, I can tell you that as a developer, having only a few "apps" that internally have hundreds of services, has more or less freed us up of having to worry about any of that cognitive (and performance) overhead.
Basically you could split up your apps and hack on them independently (but actually have a good way to share dependencies if needed) and at deploy time you could choose to deploy all of them, or just the ones you want.
Phoenix (Elixir's goto web framework) also tries to nudge you in a good direction to split up your code base in a way that allows you to separate the specific pieces of your app. This is really good for people who just want to make maintainable projects. It's sort of like the first step in splitting up your application without dealing with any type of real additional complexity since changing things around just involves renaming and moving files.
You can put an Erlang/Elixir app into a container and deploy it, but containerization doesn't provide as much value as it may for other languages. The Erlang VM doesn't depend much on the operating system. The mix build tool tightly manages runtime library dependencies, and building a release combines the VM and the app's libraries into a single tarball that you can deploy as a unit. So we don't find it particularly useful to use Docker/Kubernetes to deploy.
Erlang/Elixir makes it very easy to take advantage of all the CPU cores available, so you generally benefit from having one instance with lots of CPUs instead of lot of little instances. And it can be a lot cheaper to do this in a dedicated server environment instead of the cloud.
So on the whole, Kubernetes is not that big a win for Erlang, but they work fine together.
1. Our jenkins CI builds a docker image which contains an erlang release (using distillery).
2. This image gets pushed to ECR (AWS's image repository), every version is tagged with a $GIT_REF.
3. We have another jenkins job which updates our AWS ECS Tasks to use the new version of Docker images.
4. AWS ECS now spins up a few new containers and drains out the connections from the old ones.I have written a detailed guide here: https://www.cogini.com/blog/best-practices-for-deploying-eli...