Cloud Foundry provides developers with several choices of frameworks, application infrastructure services and deployment clouds. This approach to providing a platform as a service enables the fast creation of useful cloud applications that take advantage of polyglot programming and multiple data services. As an example of how this enables us to be more productive, I was able to use Node.js, Redis, and MongoDB to create an Activity Streams application in a short time, despite the fact that I mainly develop Web Applications in Ruby. Based on the developer interest after a demo of this application at NodeSummit 2012 and MongoSF 2012, I was inspired to do a 3 part blog series that fully details the creation, deployment, and scaling of this application on CloudFoundry.com.
In my previous post, I talked briefly about the vcap repo refactoring effort. This week, I want to walk you through the process in a little more detail.
If you look closely at the vcap repo, you can see that it’s a collection of major system components (dea, cloud controller, health manager, etc.). This structure is not a scalable structure for the long haul on a number of fronts.
For instance, when building releases we often find ourselves wanting different components at different stages of completion. Within the cf-release repo, we currently have a single sub-module pointer to vcap (src/core). Given the component diversity under vcap, we often find ourselves wanting to be able to manage one launch schedule for each component (e.g.