Previously, developers had to put a lot of energy into preserving choice across operating systems and minimizing hard dependencies on specific operating systems. In the cloud era, there is a similar challenge to preserve choice across clouds and minimize dependencies on specific clouds.
Most PaaS solutions today force you to write your application to that specific PaaS and that is where your app will stay, much like writing to an OS. It sits on a public cloud somewhere and cannot be moved without recoding and dependency swaps. In extreme cases, you as a developer are still directly tied to the constraints of the infrastructure.
Limiting yourself to a single cloud instance restricts your flexibility now and in the future. You may want to move from private to public cloud, or vice versa. You may want to change from one public cloud provider to another or maybe you are dissatisfied with the pricing or reliability from a particular provider. Geographic market expansion or compliance needs may push you to new clouds. Building and deploying applications to clouds that have a proprietary deployment and/or technology stack will impede your cloud flexibility. You want to preserve your “Multi-Cloud” ability.
Cloud Foundry gives you the ability to make your application Multi-Cloud by allowing you to write your application once and deploy it to any Cloud Foundry instance, be it public or private or even on to Micro Clouds.
The Cloud Foundry eco-system has grown a great deal in the last 9 months. There are now multiple public clouds based on Cloud Foundry and several private cloud deployment options that rely on Cloud Foundry. In addition, we also offer Micro Cloud Foundry (Cloud Foundry in a VM). All of these options have the ability to take the same Java, Ruby, or other code and deploy an application without modification.
How does Cloud Foundry achieve Multi-Cloud Application Portability?
There are several technologies at work to make Multi-Cloud a reality.
DEAs – The Dynamic Execution Agents operate as independent entities that carry out requests made by the Cloud Controller. By being independent, DEAs provide a place for the Application to run without the application being aware of where it is executing (like in a traditional OS).
Service Gateways – Provide a common/uniform way of exposing Services (Databases, Message Queues, Stores, etc.) to the Applications running on the DEAs. By presenting services in a common and uniform way to a running application, it becomes more easily portable.
Environmental Variables – The last portion to make applications portable is to provide credentials for services in a standard way to all application runtimes. In all Cloud Foundry implementations, this is done by injecting a JSON document as an environment variable that lists all bound services and their credentials to the Application. Once a developer has written their code to leverage this (either by parsing the JSON themselves or by leveraging a framework feature such as Spring 3.1 Profiles, the application can be run on any instance of Cloud Foundry without modification to any of the code.
Below is a 5 Minute video showing a Multi-Cloud Deployment to 5 different Cloud Foundry based Clouds
Multi-Cloud using Cloud Foundry – The Demo
(For the fully detailed 13 minute version, click here)
Steve Herrod, VMware’s Chief Technology Officer further discusses the advantages of the Multi Cloud approach to PaaS in the following blog post.
Watch a short flash video – “Multi-Cloud and Proud”
-The Cloud Foundry Team
Don’t have a Cloud Foundry account yet? Sign up for free today
About the Author
