incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Darren Shepherd" <dar...@godaddy.com>
Subject RE: [Discuss] CloudStack architecture to a loosely-coupled component oriented distributed architecture
Date Mon, 20 Aug 2012 16:59:31 GMT





> -------- Original Message --------
> Subject: Re: [Discuss] CloudStack architecture to a loosely-coupled
> component oriented distributed architecture
> From: Chip Childers <chip.childers@sungard.com>
> Date: Mon, August 20, 2012 6:55 am
> To: cloudstack-dev@incubator.apache.org
> 
> 
> On Mon, Aug 20, 2012 at 9:53 AM, Alex Huang <Alex.Huang@citrix.com> wrote:
> >>
> >> http://www.cloudscaling.com/blog/cloud-computing/simplicity-scales-an-
> >> alternative-approach-to-openstack-nova-rpc-messaging/
> >>
> >> Zeromq seems good.
> >> >
> >
> > I like 0mq as well but it's LGPL.  I've been reading up on the whole apache compatibility
license thing and there doesn't seem to be a way around it.  It has to be optional component.
> >
> > So I believe this is crucial.  The underlying messaging infrastructure should be
switchable then people can use whatever they want, including 0mq.  So to discuss what the
underlying mechanism is right now is beside the point.  First Murali and Kelven needs to develop
their respective abstraction layer.
> >
> > --Alex
> >
> 
> +1 - We can get to the "out of the box" messaging system selection
> after understanding the abstractions and logical relationships (if
> there are any in the end).

I agree its important to have a messaging abstraction layer up front. 
The specific implementation can be decided later and should be pluggable
(I too would like 0mq, that darn LGPL).  What most people over look with
messaging is it not really important what MQ implementation you use
(that can easily be changed), but instead HOW you use it.  The how is
what ends up causing problems if not thought through properly.  For
example, if you do a simple event driven system and then your billing
system works off of those events, you've just put yourself into a
messaging pattern that requires persistent and transactional messaging
(which is more complex to scale).  So, just food for thought.

Darren

Mime
View raw message