On 16/08/12 5:55 AM, "Chip Childers" <chip.child...@sungard.com> 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 >consider. 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). > >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 >itself. Yes, if there is richer message bus capable of distributed delivery then we need to reconsider event notification.
