Open Stack

Excerpts from Joe Gordon's message of 2014-09-23 14:59:33 -0700:
> On Tue, Sep 23, 2014 at 9:13 AM, Zane Bitter <zbitter at redhat.com> wrote:
> 
> > On 22/09/14 22:04, Joe Gordon wrote:
> >
> >> To me this is less about valid or invalid choices. The Zaqar team is
> >> comparing Zaqar to SQS, but after digging into the two of them, zaqar
> >> barely looks like SQS. Zaqar doesn't guarantee what IMHO is the most
> >> important parts of SQS: the message will be delivered and will never be
> >> lost by SQS.
> >>
> >
> > I agree that this is the most important feature. Happily, Flavio has
> > clarified this in his other thread[1]:
> >
> >  *Zaqar's vision is to provide a cross-cloud interoperable,
> >   fully-reliable messaging service at scale that is both, easy and not
> >   invasive, for deployers and users.*
> >
> >   ...
> >
> >   Zaqar aims to be a fully-reliable service, therefore messages should
> >   never be lost under any circumstances except for when the message's
> >   expiration time (ttl) is reached
> >
> > So Zaqar _will_ guarantee reliable delivery.
> >
> >  Zaqar doesn't have the same scaling properties as SQS.
> >>
> >
> > This is true. (That's not to say it won't scale, but it doesn't scale in
> > exactly the same way that SQS does because it has a different architecture.)
> >
> > It appears that the main reason for this is the ordering guarantee, which
> > was introduced in response to feedback from users. So this is clearly a
> > different design choice: SQS chose reliability plus effectively infinite
> > scalability, while Zaqar chose reliability plus FIFO. It's not feasible to
> > satisfy all three simultaneously, so the options are:
> >
> > 1) Implement two separate modes and allow the user to decide
> > 2) Continue to choose FIFO over infinite scalability
> > 3) Drop FIFO and choose infinite scalability instead
> >
> > This is one of the key points on which we need to get buy-in from the
> > community on selecting one of these as the long-term strategy.
> >
> >  Zaqar is aiming for low latency per message, SQS doesn't appear to be.
> >>
> >
> > I've seen no evidence that Zaqar is actually aiming for that. There are
> > waaay lower-latency ways to implement messaging if you don't care about
> > durability (you wouldn't do store-and-forward, for a start). If you see a
> > lot of talk about low latency, it's probably because for a long time people
> > insisted on comparing Zaqar to RabbitMQ instead of SQS.
> >
> 
> I thought this was why Zaqar uses Falcon and not Pecan/WSME?
> 
> "For an application like Marconi where throughput and latency is of
> paramount importance, I recommend Falcon over Pecan."
> https://wiki.openstack.org/wiki/Zaqar/pecan-evaluation#Recommendation
> 
> Yes that statement mentions throughput as well, but it does mention latency
> as well.
> 

I definitely see where that may have subtly suggested the wrong
thing, if indeed latency isn't a top concern.

I think what it probably should say is something like this:

"For an application like Marconi where there will be many repetitive,
small requests, a lighter weight solution such as Falcon is preferred
over Pecan."

As in, we care about the cost of all those requests, not so much about
the latency.