> That could be ultimate goal, and it's totally reflects "unix way" - don't use > one huge universal tool, rather - set of small, > but dedicated to particular task tools. As for now i see that CS is big > monolithic complex, with tons internal, non-exposed dependencies.
I agree. Making the complex logic currently residing in system VM loosely coupled from CloudStack will greatly enhance modularity. If we make that happen, CloudStack will consists of a core orchestration module and various loosely-coupled services running on top. Examples of these services are: 1. Console proxy 2. Template and ISO distribution (e.g., caching) 3. Snapshot backup (i.e., copying snapshots from primary storage to object store) 4. API proxy (e.g., EC2, S3, etc.) 5. Load balancers and firewalls Once these services are nicely encapsulated, they can be deployed in different ways: 1. It makes sense to deploy certain services on dedicated physical servers. For example, Snapshot backup service needs direct access to storage network and massive network throughput. It runs the best on dedicated physical servers. 2. A lightweight developer setup can have all these services deployed on a single laptop or in a single application server. This simplifies debugging and troubleshooting. 3. CloudStack should continue to offer a system VM framework. Some or all of these services can be deployed into system VMs (just like today.) This approach has certain benefits as well because CloudStack can automatically manage the lifecycle of system VM, automatically monitor the system VM, and automatically scale the number of system VMs to respond to the load. Sheng
