VMware’s Cloud Foundry release has the potential to be quite a watershed moment for the PaaS world. It provides many of the core pieces that are needed to build a PaaS in an open source form. VMware has put it together in such a way that it is easy to construct PaaS deployments of various sizes and also to plug in different management strategies. All this dovetails nicely with RightScale in that we are providing multiple deployment configurations for Cloud Foundry and will add management automation over the coming months.
Advent of Private PaaS
Until now the notion of PaaS has lumped together the author of the PaaS software and its operator. For example, Heroku developed its PaaS software and also offers it as a service. If you want to run your application on Heroku your only choice is to sign up to their service and have them run your app. Google AppEngine has the same properties. All this is very nice and has many benefits, but it doesn’t fit all use cases by a long shot. What if you need to run your app in Brazil but Heroku and your PaaS service doesn’t operate there? Or if you need to run your app within the corporate firewall? Or if you want to add some custom hooks to the PaaS software so you can punch out to custom services that are co-located with your app? All these options become a reality with Cloud Foundry because the PaaS software is developed as an open source project. You can customize it and you can run it where you want to and how you want.
Of course you can also go to a hosted Cloud Foundry service whenever you don’t want to be bothered running servers. This could be a public Cloud Foundry service that is in effect competing with Heroku, AppEngine and others, but it could also be a private service offered by IT or your friendly devops team mate. This opens the possibilities for departmental PaaS services that may have a relatively small scale and can be tailored for the specific needs of their users.
Benefits of PaaS
PaaS is really about two things: simplicity of deployment and resource sharing. The way a PaaS makes deployment simpler is by defining a standard deployment methodology and software environment. Developers must conform to a number of restrictions on how their software can operate and how it needs to be packaged for deployment. Restrictions is perhaps the wrong word here, a set of standards is a better way to phrase it because just as some flexibility is lost a lot of benefits are gained out of the box. It’s similar to no longer writing applications that tweak device interfaces directly and instead have to go through a modern operating system device driver interface. In the PaaS context, instead of having custom deployment and scaling methodologies for each application there is a standard contract. This makes for much simpler and cheaper deployment and reduces the amount of interaction necessary between the teams that produce applications and those that run it.
Resource sharing is a second benefit of PaaS in that many applications can time-share a set of servers. This is similar to virtualization but at a different level. Where this resource sharing becomes interesting is when there are many applications that receive an incredibly low average number of requests per second. For example, a corporate app that is used once a quarter for a few days is likely to receive just a trickle of requests at other times. If virtualization were used then at least some virtual machines would have to be consuming sufficient resources to keep the operating system ticking, the monitoring system happy, log files rotating and a number of other things that are just difficult to turn off completely without shutting the VMs down, which may not be desirable for a number of reasons. In a PaaS the cost of keeping such applications alive drops down significantly.
PaaS running in IaaS – Cloud Foundry with RightScale
PaaS is sometimes believed to be at odds with IaaS, as if you have to choose one or the other. We believe in both models and CloudFoundry starts to fulfill that vision. RightScale enables Cloud Foundry to be deployed in a number of different configurations that vary in size, in location, in underlying cloud provider, in geographic location, or in who controls the deployment or pays for it.
With RightScale it becomes easy to set up a number of Cloud Foundry configurations for different use cases. It is possible to set up a large deployment for many applications and really leverage the resource sharing benefits. But as some applications mature and have more stable resource needs and perhaps need to be separated from other to improve monitoring, resource metering, or allow for customization this can be easily accomplished by launching appropriate deployments. Finally, some applications may outgrow the capabilities of a PaaS environment and require a more custom deployment architecture.
Try it out!
We’ve created an All-In-One ServerTemplate in RightScale that launches Cloud Foundry in one server on Amazon EC2. If you do not have a RightScale account you can sign up for one free (you will have to pay for the EC2 instance time though). The ServerTemplate is called Cloud Foundry All-In-One. When you launch it, take a coffee, and come back, and you’ll be able to load your apps up! (Note that currently a lot of components are compiled at boot from the source repositories, so the server takes ~10 to 15 minutes to boot, we will be optimizing that as soon as the code base settles down a bit.)
I must say that this is one of the more exciting cloud developments in a while. I’ve been wanting to add good PaaS support to RightScale for a long time and Cloud Foundry is now making it possible. We’ve been talking to Mark Lucovsky about his secret project for many moons and it’s really refreshing to see the nice clean simple architecture he and his team (hi Ezra!) have developed see the light of day. We’re now planning RightScale features around PaaS support so please let us know what you’d like to see from us!
NB: I had wanted to write about the architecture of Cloud Foundry and how it fits with RightScale ServerTemplates, but the timing was too tight. Stay tuned for a follow-on post on Cloud Foundry Architecture and Auto-Scaling.