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.
My point is that you can achieve many of the same benefits of microservices within a single app (or "vm" in erlang terms).
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.
And to further add to this. When he says "same benefits of microservices within a single app", that's because there's this concept of an "Umbrella app".
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.
I would say they are complementary. Kubernetes is a standard solution for packaging and deploying apps. If you run a lot of apps, you want your ops team to be able to manage them without knowing all the details. You get better utilization of your servers by allowing them to deploy standard units and manage resources at a higher level.
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.
I also want to know this. We have a team of 3 people maintaining our microservices infra (services written in NodeJS), out of ~15 developers. It feels like a waste, these (monitoring, logging, deployment etc) are all problems that have been solved many times over.
I'll share our deployment stack with Elixir, which is pretty hands off. We use docker with AWS ECS and have a simple release process:
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.
We run in cloud or dedicated server instances. We deploy using Erlang "releases" using systemd for process supervision. We build on a continuous integration server and deploy using Ansible or AWS CodeDeploy.
