Open Stack

On 09/23/2014 11:59 PM, Joe Gordon wrote:
> 
> 
> On Tue, Sep 23, 2014 at 9:13 AM, Zane Bitter <zbitter at redhat.com
> <mailto: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.

Right, but that doesn't make low-latency the main goal and as I've
already said, the fact that latency is not the main goal doesn't mean
the team will overlook it.

>  
> 
> 
>     (Let's also be careful not to talk about high latency as if it were
>     a virtue in itself; it's simply something we would happily trade off
>     for other properties. Zaqar _is_ making that trade-off.)
> 
>         So if Zaqar isn't SQS what is Zaqar and why should I use it?
> 
> 
>     If you are a small-to-medium user of an SQS-like service, Zaqar is
>     like SQS but better because not only does it never lose your
>     messages but they always arrive in order, and you have the option to
>     fan them out to multiple subscribers. If you are a very large user
>     along one particular dimension (I believe it's number of messages
>     delivered from a single queue, but probably Gordon will correct me
>     :D) then Zaqar may not _yet_ have a good story for you.
> 
>     cheers,
>     Zane.
> 
>     [1]
>     http://lists.openstack.org/__pipermail/openstack-dev/2014-__September/046809.html
>     <http://lists.openstack.org/pipermail/openstack-dev/2014-September/046809.html>
> 
> 
>     _________________________________________________
>     OpenStack-dev mailing list
>     OpenStack-dev at lists.openstack.__org
>     <mailto:OpenStack-dev at lists.openstack.org>
>     http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
> 
> 
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
@flaper87
Flavio Percoco