Hacker News Reader

Comment by latch | Hacker News Reader

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.

View on HN

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 have to ask someone to bring kubernetes into the comparison -redundant with Erlang?

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 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.

Reply on news.ycombinator.com