InfoQ recently talked to Derek Collison, CTO and Chief Architect for Cloud Systems at VMware, about his company’s new open source PaaS offering called Cloud Foundry.
InfoQ: How would you describe Cloud Foundry to an Architect? How about a CIO?
Derek: Cloud Foundry is VMware's OpenPaas, with support for multiple frameworks and languages, and a choice of cloud platform and application services. It is a distributed system designed to allow a developer's application, and associated services, to take center stage while abstracting away issues commonly associated with IaaS. The system itself has been designed to be self healing and horizontally scalable at each level, applicable to run in a large datacenter, or even on a single laptop, all with the same code base.
Expanding the system can be done without downtime underneath of active users and applications. The system is decoupled from the underlying infrastructure and therefore easy to get running within any IaaS layer. User interaction with the system is consistent across multiple cloud targets, and is based on an HTTP REST interface which anyone can implement. Being open source adds a level of comfort for architects and CIOs interested in running their own implementation, or accessing one of the services based on the Cloud Foundry architecture and code.
The system takes care of load balancing and high-availability for all application instances. Applications that fail for any reason are restarted automatically, and multiple instances are load balanced from the router pool in real-time. Scaling up and scaling down is fast and efficient, allowing a developer or release engineer multiple options for scaling and high availability. Access to services, and binding your application to services, is simple and straightforward, allowing different design patterns to emerge for the application developer. Application and service level security can range from multi-tenant, with process, file system, and user level isolation, to full hypervisor level isolation.
InfoQ: The debate continues to rage on between public vs. private clouds. What do you think that Cloud Foundry will do to this debate? Move it forward? Make it less relevant?
Derek: I believe the argument is still relevant. There are different circumstances and requirements that drive these types of choices. With Cloud Foundry, the choice becomes less of an impact on developer productivity and business agility, and more of a business decision. We think it’s is a good thing. An application deployed in a public cloud using Cloud Foundry can be re-targeted to a private instance with little to no effort. We believe our pledge to the Developer Rights gives customers the widest range of choices available in the market today, from utilizing a public service like Cloud Foundry, to bringing the system in house, and everything in between.
During the launch event we deployed the same application to Cloud Foundry the service, which is backed by our own VSphere technology, to Cloud Foundry running on Amazon, with support from our partner RightScale. We concluded with deployment of the same application to a private instance running on a single laptop. All environments were identical in terms of the services they offered and the user interaction mode, none of the commands changed, none of the system code changed, and none of the application code changed.
So whether it's public, private, or hybrid, we think Cloud Foundry is a great start to developer productivity and business agility and the OpenPaaS.
InfoQ: Where do you hope to see the most community contributions to Cloud Foundry?
Derek: I think they will come in waves as the community embraces the system to be fit their own needs. Cloud Foundry in some respects has enabled the personalized PaaS. First you will see languages and frameworks and service offerings. We already have substantial pull requests in both of these areas, and we expect this trend to continue. I expect long term though that most contributions will fall in tooling and management as the frameworks and services stabilize.
InfoQ: The Google App Engine doesn't allow all standard code libraries to run in their PaaS environment. What are some of the built-in limitations of the software deployed to Cloud Foundry? What can't you do there that you can do in a totally controlled infrastructure?
Derek: We have strived to allow most modern applications, services, and code libraries to be utilized in Cloud Foundry without modification. We took an early stance that being "Cloud Ready" should not mean a total rewrite of your application.
Certain things are still not possible, such as binding to port 80, or writing to a random directory outside of your application container. We also monitor the application's resource usage quite carefully. But if you have an application that utilizes standard code libraries, a modern framework to access a database, and maybe uses Redis for some caching, we think that should be possible with minimal or no effort to run in the cloud.
InfoQ: How do you think the recent AWS service outages will affect architects looking at cloud solutions? Do the portability promises of Cloud Foundry create a looser affinity to a particular hosting provider?
Derek: AWS has blazed a trail that all of us have learned and benefitted from. We are still in the very beginning of the cloud era, and there are still some very hard lessons to be learned by all. Cloud Foundry represents VMware's attempt to truly define an OpenPaaS that gives customers choice in terms of providers, public vs private vs hybrid deployments, application frameworks and runtimes, and services.
Choice is good.