[openstack-dev] [marconi] Reconsidering the unified API model

Kurt Griffiths kurt.griffiths at rackspace.com
Tue Jun 10 17:12:36 UTC 2014


> 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




More information about the OpenStack-dev mailing list