zlacker

>>mpweih+(OP)
I think this is a decent response - they really nail what @rbranson misses, that the failures he mentions are actually features we're after.

An example,

> Convert something to an async operation and your system will always return a success response. But there's no guarantee that the request will actually ever be processed successfully.

Great! I don't want service A to be coupled to service B's ability to work. I want A to send off a message and leave it to B to succeed or fail. This separation of state (service A and B can't even talk to each other directly) is part of what makes queues so powerful - it's also the foundation of the actor model, which is known for its powerful resiliency and scalability properties.

The author's suggestion of using synchronous communication with backpressure and sync failures is my last ditch approach. I have to set up circuit breakers just to make something like this anything less than a total disaster with full system failure due to a single service outage.

Like the author, the "good use cases for queues" is very nearly 100% for me. I believe you should reach for queues first, and it's worth remodeling a system to be queue based if you can help it.

Sometimes modeling as synchronous control is easiest, but I'm happy that I can avoid that in almost every case.

>>static+dR
> Convert something to an async operation and your system will always return a success response.

It's funny reading this after using Erlang/Elixir over the last few years. The default is always async with the assumption it will fail - as async processes failing is a core part of the OTP application architecture.

It's not something to be feared but a key part of how your application data-flow works.

>>dmix+jS
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+LT
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+db1
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.