Open Stack

On Mon, Sep 22, 2014 at 5:47 PM, Zane Bitter <zbitter at redhat.com> wrote:
> On 22/09/14 17:06, Joe Gordon wrote:
>>
>> If 50,000 messages per second doesn't count as small-to-moderate then
>> Zaqar
>> does not fulfill a major SQS use case.
>
>
> It's not a drop-in replacement, but as I mentioned you can recreate the SQS
> semantics exactly *and* get the scalability benefits of that approach by
> sharding at the application level and then round-robin polling.
>

This response seems dismissive to application developers deciding what
cloud-based messaging system to use for their application.

If I'm evaluating two messaging services, and one of them requires my
application to implement autoscaling and pool management, and the
other does not, I'm clearly going to pick the one which makes my
application development *simpler*. Also, choices made early in a
product's lifecycle (like, say, a facebook game) about which
technology they use (like, say, for messaging) are often informed by
hopeful expectations of explosive growth and fame.

So, based on what you've said, if I were a game developer comparing
SQS and Zaqar today, it seems clear that, if I picked Zaqar, and my
game gets really popular, it's also going to have to be engineered to
handle autoscaling of queues in Zaqar. Based on that, I'm going to
pick SQS. Because then I don't have to worry about what I'm going to
do when my game has 100 million users and there's still just one
queue.

Granted, it has become apparent that Zaqar is targeting a different
audience than SQS. I'm going to follow up shortly with more on that
topic.

-Devananda