On Mon, Sep 22, 2014 at 5:47 PM, Zane Bitter <zbit...@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 _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
