As development teams seek to rent application platforms rather than own application platforms, team members place greater emphasis on application interoperability and portability. Open Cloud initiatives and Cloud specifications seek to increase platform interoperability, enhance application portability, and assuage lock-in concerns.
The open source VMware Cloud Foundry project attempts to standardize application management and application deployment. VMware’s strategy is to establish a de facto application deployment standard by reaching critical ecosystem mass.
In response, VMware’s competitors (e.g., Oracle, Red Hat) recently announced a specification “to manage the building, running, administration, monitoring and patching of applications in the cloud.” The Cloud Application Platform Management Specification (CAMP) promises to increase “consumers’ ability to port their applications between Platform as a Service (PaaS) offerings” and “enable interoperability among self-service interfaces to PaaS clouds.”
Migrating or moving applications across Cloud application platform service providers is currently a difficult task, and end-users are limiting PaaS adoption out of concern for platform management interoperability. Each provider currently requires vendor-specific deployment tooling, unique deployment manifest meta-data, non-standard topology definitions, and proprietary cloud services (i.e., load-balancing, identity, authorization).
Vendor-specific Command Line Interface (CLI) tools or Eclipse hosted deployment plug-ins are highly visible lock-in points. Other less visible lock-in points include application topology limits, security policies, user roles, and database locations.
CAMP defines “artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud.” The stated specification goal is to “provide the PaaS with a model that is as simple as possible, and yet still provides the essential elements that give them control over the deployment, execution, administration and metering of their application and its deployment environment.”
The interoperability and portability promise is seductive, and open specifications position customer choice as a risk-free proposition. Even with the best service provider intentions, delivering application interoperability across multiple service provider platform offerings is difficult, time-consuming, and often devolves into offering a simple commodity service.
Achieving interoperability will require tightly specifying platform capabilities and service level policies as standard metadata. Significant future work is required to define application platform metadata, standardize provider services, and implement interoperable solutions.
Seamlessly migrating an application across cloud service providers and achieving desired portability will require preventing lock-in within application platform stack layers. Simplicity often encourages adoption and decreases available lock-in surface area.
The broad scope of the OASIS Cloud Application Management for Platform charter reminds me of WS-* and Java EE complexity. The charter’s scope is extremely broad, and fulfilling the interoperable promise for all the eleven charter work items required to deliver a cloud-aware application (as opposed to a simple application in the cloud) will take considerable effort, time, and vendor commitment.
For more on Achieving Cloud Application Portability, Cloud Management Interoperability, and Reducing Cloud Provider Lock-in, read Chris Haddad's Managing the Cloud Application Lifecycle and Enhancing Cloud Application Portability Across Clouds.
