zlacker

I've been planning on giving Erlang/Elixir a try, but we are very reliant on serverless and managed cloud services (like SQS) and I get the impression that managing a cluster of worker nodes for Erlang/Elixir would be too much work for us, since we would have to manage the servers, security patches, plan its scaling, etc.

Maybe I'm wrong and it's not so much work in the end. Hoping for some feedback.

>>haolez+(OP)
My opinion is that the actor model, today, is best expressed through queue based microservices, especially on something like AWS lambda. If you're already follow microservice best practices, using async communication, there's a good chance that you're already benefiting from an actor oriented system.

>>haolez+(OP)
The learning curve I've experienced with Elixir, after working previously with managed services, in handling the above-mentioned tasks while managing state in the BEAM cluster. Patches are scaling are straightforward if you can restart instances and assume they can pick up what was interrupted before, but hot-reloading or managing state between nodes in a rolling update with give you overhead as you get set up.

What it works really great for if you don't want to do the up front investment in managing a stateful cluster, is doing multi-step or fan-out processing. BEAM/OTP really shines when it's helpful to have individual processing steps coordinated but isolated, but where if a job needs to cancel and rerun (interrupted by a node restart or OOM), it's not an issue.

This is great resource https://www.erlang-in-anger.com/

>>haolez+(OP)
I’d love to know how this isn’t true as well, but I was in an environment where cross-az network costs were something we were continuously mitigating against. Using stuff like sqs let us build cross-az availability with 0-metered network costs, serverless can come into play because it’s network connections usually come through 0-cost aws services as well. It seems to me like from a cost basis, getting into something with clustered erlang would kill you in many of these cloud environments (or at least you would be on the hook for engineering workarounds to keep traffic within an az w/ failover to other azs)

>>awinde+sh
That’s a good question. I’m sure there are people who could answer that. WhatsApp famously scaled an erlang app to a billion users around the world. Quite a few people have done it on a large scale. RabbitMQ is also built in Erlang and used in large deployments.

The zero cost stuff is always going to be a big draw with cloud deployments and the various demands from the company. Although a lot of this stuff like messaging and clustering/failover is within the application/Beam VM itself rather than something scaled or managed externally to the software. But that level of server and infrastructure stuff is out of my league of understanding.