61–70 of 78 posts
AMQP 0.9.1 only. Azure Service Bus supports AMQP 1.0 and does not require any servers on the tenant side.
Offtopic: we are evaluating rabbit at the moment vs activemq; rabbit won for one detail: we need delayed messages (ex. publish {...} in 2h) and activemq seems to support those clustered while rabbit only on one node, which does not fit the business case (we cannot lose messages). I worked with rabbitmq before and it was great but this seems indeed an issue. Someone here with some insights?
I'm not taking a position on whether this is an acceptable level of complexity for the desired feature, of course, just pointing out how one might accomplish it if Rabbit is otherwise desirable.
Cloud computing seems to be a winner take all scenario. For example, if you use AWS and need a message broker service then you'll use this. If you use Azure, you'll use their version. Development seems like just hooking up this components. I can't tell if this is a good thing or a bad thing.
It’s a bad thing - whenever you cannot make a choice you become a slave to tyranny. Infra lock-in means you’re a slave to their whims (financial, legal, competitivenes, whatever) This is justified by “less maintenance, and easier deployment” but the reality of the situation is, it’s not worth giving your freedom up for, and to a lesser degree - if your platform becomes popular, you end up spending the same amount of…
Earlier quoted context omitted.
> AWS has sqs & kinesis which are much better queueing options in that scenario where you’re in AWS doing new dev and can pick a technology. Why are they better?
They aren't. They're technically more correct but not always the practical best choice. RabbitMQ is a smart play as Rabbit is very easy to use, understand, and troubleshoot at the low end (which is where I suspect the vast majority of queue systems live). It also has a feature which is actually really hard to do (and sqs doesn't do). Guaranteed delivery of a message once . That was THE reason we never migrated to SQS…
That flies in the face of my distributed systems knowledge. It's not possible in some failure cases.
If your acknowledgement of a message gets lost (because either server involved or the pipes in-between fail) you've processed the message already but the queue server will think you haven't. It either has to resend it (duplicate delivery) or it ignores acknowledgements all together (drops messages that it sent you, but you didn't process - maybe because your server failed.) So the choice when there is a failure in the system is between at least once or at most once - exactly once cannot be guaranteed.
I'm not aware of any way around that predicament.
Earlier quoted context omitted.
It’s a bad thing - whenever you cannot make a choice you become a slave to tyranny. Infra lock-in means you’re a slave to their whims (financial, legal, competitivenes, whatever) This is justified by “less maintenance, and easier deployment” but the reality of the situation is, it’s not worth giving your freedom up for, and to a lesser degree - if your platform becomes popular, you end up spending the same amount of…
How is using AWS or Azure's managed RabbitMQ service lock-in? You can easily switch to someone else's managed service, or roll your own, since it's still just good old RabbitMQ.
From the FAANG, Amazon strikes me as the one using most open source code while at the same time not having much to show as open source - firecracker is a (relative) toy.
I'm curious why you'd characterize firecracker as a toy?
AMQP 0.9.1 only. Azure Service Bus supports AMQP 1.0 and does not require any servers on the tenant side.
Earlier quoted context omitted.
> AWS has sqs & kinesis which are much better queueing options in that scenario where you’re in AWS doing new dev and can pick a technology. Why are they better?
They aren't. They're technically more correct but not always the practical best choice. RabbitMQ is a smart play as Rabbit is very easy to use, understand, and troubleshoot at the low end (which is where I suspect the vast majority of queue systems live). It also has a feature which is actually really hard to do (and sqs doesn't do). Guaranteed delivery of a message once . That was THE reason we never migrated to SQS…
Earlier quoted context omitted.
They aren't. They're technically more correct but not always the practical best choice. RabbitMQ is a smart play as Rabbit is very easy to use, understand, and troubleshoot at the low end (which is where I suspect the vast majority of queue systems live). It also has a feature which is actually really hard to do (and sqs doesn't do). Guaranteed delivery of a message once . That was THE reason we never migrated to SQS…
SQS also supports FIFO queues, which have once-only delivery and ordering. Any reason those didn't work for you?
Yes we could do that, but we had already been using rabbit in a bunch of places. It made no sense to change it.