>From my perspective the key promise of Marconi is to provide a *multi-tenant*, *HTTP* based queuing system. Think an OpenStack equivalent of SQS or Azure Storage Queues.
As far as I know there are no off-the-shelve message brokers out these that fit that bill. Note that when I say ³multi-tenant² I don¹t mean just having multi-tenancy concept reflected in the APIs. The key aspect of the multi-tenancy is security hardening against a variety of attacks absent in single-tenant broker deployments. For example, an authenticated DOS attack. Thanks, Tomasz Janczuk @tjanczuk HP On 6/10/14, 10:12 AM, "Kurt Griffiths" <kurt.griffi...@rackspace.com> wrote: >> Will Marconi only support HTTP as a transport, or will it add other >>protocols as well? > >We are focusing on HTTP for Juno, but are considering adding a >lower-level, persistent transport (perhaps based on WebSocket) in the K >cycle. > >> Can anyone describe what is unique about the Marconi design with respect >>to scalability? > >TBH, I don¹t know that there is anything terribly ³unique² about it. :) > >First of all, since Marconi uses HTTP and follows the REST architectural >style, you get all the associated scaling benefits from that. > >Regarding the backend, Marconi has a notion of ³pools", across which >queues can be sharded. Messages for an individual queue may not be >sharded across multiple pools, but a single queue may be sharded >within a given pool, depending on whether the driver supports it. In >any case, you can imagine each pool as encapsulating a single DB or >broker cluster. Once you reach the limits of scalability within your >initial pool (due to networking, hard limitations in the given backend, >etc.), you can provision other pools as needed. > >> in what way is Marconi different to 'traditional message brokers' (which >>after all have been providing 'a production queuing service' for some >>time)? > >That¹s a great question. As I have said before, I think there is certainly >room for some kind of broker-as-a-service in the OpenStack ecosystem that >is more along the lines of Trove. Such a service would provision >single-tenant instances of a given broker and provide a framework for >adding value-add management features for said broker. > >For some use cases, such a service could be a cost-effective solution, but >I don¹t think it is the right answer for everyone. Not only due to cost, >but also because many developers (and sys admins) actually prefer an >HTTP-based API. Marconi¹s multi-tenant, REST API was designed to serve >this market. > >> I understand that having HTTP as the protocol used by clients is of >>central importance. However many 'traditional message brokers¹ have >>offered that as well. > >Great point. In fact, I¹d love to get more info on brokers that offer >support for HTTP. What are some examples? Do they support multi-tenancy? > >-KG > > >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
