incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kelven Yang <>
Subject Re: [Discuss] CloudStack architecture to a loosely-coupled component oriented distributed architecture
Date Thu, 16 Aug 2012 04:36:55 GMT

On 8/15/12 6:44 PM, "Murali Reddy" <> wrote:

>On 16/08/12 5:55 AM, "Chip Childers" <> wrote:
>>The only hesitation that I have is around ease of installation /
>>configuration.  CloudStack is great at this today (one of the reasons
>>that my company gravitated to it), and I don't want to lose that
>>value.  I don't think this is a blocker to distributing the system at
>>all, but it will be a critical design and implementation detail to
>Agree with Chip, this is critical design decision. Message oriented
>distributed service architecture will be a fundamental shift from what
>CloudStack is today. If the goal is just to have loose coupling between
>the components what other option can be evaluated? Now that we move to
>maven/gradle can dependency management solve some of the coupling issues?
>Lets say CloudStack core is broken into orchestration, compute, storage
>and network components and then its easy to impose dependency that
>orchestration component can depend on compute, storage, network
>components, but compute can not depend on network component etc. Other
>option is having in-process message bus for component IPC which may give
>same decoupling benefits and retain the current benefits (horizontally
>scaling management server and ease of installation and configuration).

I've been under the same impression before that by applying loosely-couple
principal should solve the problem. But more and more evidences show that
a distributed, component-oriented architecture is in the center of the
stage, the benefits of such architecture seem to have more weight than the
other way around, ease of deployment under such architecture can
technically be solved to a level that satisfies most of the needs.

>>How do you see this matching up with Murali's Event notification
>>framework proposal?  It seems to me, that switching to a distributed
>>model requires a shift in his thinking on the actual event framework
>Yes, if there is richer message bus capable of distributed delivery then
>we need to reconsider event notification.

View raw message