Enhancing Cloud Application Portability across Clouds
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 may devolve into offering a simple commodity service.
Seamlessly migrating applications across cloud service providers and achieving desired portability will require preventing lock-in within application platform stack layers and standardizing relevant policy definitions. Enabling cloud-aware application portability will require defining meta-data parameterizing cloud characteristics.
The Cloud Application Management for Platforms (CAMP) specification states management API benefits could include “increasing the portability of applications between PaaS offerings.” Application portability across clouds is determined by architecture dependencies, not management interfaces.
Application packages experience limited portability whenever the application components are locked into a specific technology alternative across one or more application stack layers. Application stack layers may include the following:
- Programming language (e.g., Java, JavaScript, Ruby, Sinatra, Scala)
- Application framework API (e.g., jQuery, Java EE, Map-Reduce)
- Application configuration data (e.g., web.xml, web.config, .gemrc, Spring annotations)
- Data model (i.e., key-value, relational, XML, object, graph)
- Application server (i.e., implements passivation, session management, node coordination, resource bundles, resource pooling, network protocols, file i/o)
- Application container (i.e., implements memory management, threads, code loading, security manager)
- Guest OS (i.e., implements process execution, security)
- Infrastructure-as-a-Service (i.e., delivers compute, storage, network i/o)
Java EE Application Platform vendors (i.e., Oracle, RedHat, CloudBees) traditionally embrace programming language homogeneity, fulfill application framework API interoperability (i.e., the Java EE specification and profiles), compete on application server capabilities (i.e., Quality of Service, security, and management), and lock-in applications at the application configuration layer (i.e., JMS provider, topology).
Java application servers diminish portability by requiring server-specific deployment descriptors. As application servers move into the cloud, traditional lock-in points will not evaporate. Achieving portability benefits will require rigorous deployment packaging definition and symmetric capability support.
To achieve application interoperability across diverse service provider platforms, common policy definitions, which may be a source of vendor competition and lock-in, must be normalized. Relevant policy definitions include:
- QoS management policies (i.e., reliability, availability, scalability)
- Security policies
- Resource pooling policies
- Tenant reservation policies
- Platform partitioning policies
- Network configuration
Cloud-aware application portability and platform interoperability will only occur after service providers implement elastic scale, resource pooling, and measured service (three key cloud characteristics) in an interoperable and portable manner. Otherwise, cloud consumers are simply able to portably migrate static terrestrial applications into the cloud, yet not benefit from cloud topology, flexible platform resource allocation, and granular usage-based pricing.
The specification defines how to deploy traditional applications into the cloud using on-demand self-service application deployment and does not directly address three other critical cloud characteristics (i.e., elastic scale, resource pooling, measured service). The CAMP specification explicitly defines elastic scaling (a key cloud characteristic) as out of scope: “The actual scaling architecture for a Platform Component is outside the scope of this specification.”
Section D.2 within the CAMP specification describes how scaling complexity impacts application assemblies and components but does not describe how scaling or resource pooling is addressed within the deployment package. However, the CAMP specification may be only the beginning.
The OASIS CAMP Technical Committee Charter describes a future focus on usage metering and billing, repository integration, service composition, performance monitoring, and capability discovery that will potentially increase a platform’s cloud characteristics.
For more on achieving cloud application portability, cloud management interoperability, and reducing cloud provider lock-in, read Chris Haddad's Announcing Cloud Application Management Platform Specification and Managing the Cloud Application Lifecycle.
