Hi Flavio,

On 09/04/2014 08:08 AM, Flavio Percoco wrote:
- Concern on should we really reinvent a queue system rather than
piggyback on one

As mentioned in the meeting on Tuesday, Zaqar is not reinventing message
brokers. Zaqar provides a service akin to SQS from AWS with an OpenStack
flavor on top. [0]

On 09/04/2014 01:13 PM, Flavio Percoco wrote:
If we put both features, multi-tenancy and multi-protocol, aside for a
bit, we can simplify Zaqars goal down to a "messaging service for the
cloud".  I believe this is exactly where the line between Zaqar and other
*queuing*  technologies should be drawn. Zaqar is, at the very end, a
messaging service thought for the cloud whereas existing queuing
technologies were not designed for it.

Isn't this the real answer to the concern above? Zaqar *is* a reimplementation of a messaging service, but you believe it is *necessary* to do this because existing implementations would not lend themselves to being as well integrated into the 'cloud', or do not provide sufficient support for multi-tenancy.

I suspect if you asked, you would find that many existing projects implementing a messaging service would see their solution as very much suitable for the cloud. You disagree and probably with good reason. I'm just pointing out the dividing line is I think not as clear to everyone as it may be to you. If you add support for STOMP, MQTT, AMQP or any other protocol the overlap with other messaging services will be ever greater (and will bring in new requirements and new expectations around performance).

This is not intended as criticism of Zaqar in anyway. In my opinion, 'reinvention' is not necessarily a bad thing. It's just another way of saying innovative approach and/or original thinking, both of which are good and both of which I think are important in the context of communicating in the cloud.

My concern would be more that Zaqar's privileged status as the officially 'blessed' "messaging service for the cloud" - which is a broad space, much broader than just an SQS equivalent - would make it harder for other approaches to gain traction.


OpenStack-dev mailing list

Reply via email to