Managing the Cloud Application Lifecycle
To migrate and maintain applications in the cloud, teams must first understand how to manage cloud application lifecycle phases. Development and operations team members responsible for deploying applications into the cloud must currently learn proprietary practices to build, run, administer, monitor, and patch applications.
The technology and tooling educational investment currently locks the applications into specific providers and Platform as a Service (PaaS) stacks. Vendors are positioning interoperable specifications that promote application portability and reduce lock-in concerns.
The recently announced Cloud Application Management Platform specification (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.”
CAMP’s initial Cloud Application Lifecycle is illustrated above. CAMP focuses on two distinct and important use cases. The first use case is describing how to build and package the application. The second use case describes how to deploy and manage the applications.
To specify application build, package, and deploy, CAMP defines the following first-class resources:
Assembly: a running application comprises components
Platform: what the application runs on
Component: a service, library, dataset, or collection used by the assembly or platform
Deployment Plan: management metadata, assembly template, and components
Platform and component resources are composed into a deployment plan by defining templates, requirements, and capabilities. Capabilities specify a range of configuration values, and requirement definitions narrow the capability range into a distinct resolution. Templates bundle requirements and components into a distinct solution offering.
The CAMP application lifecycle process includes deployment packages that bundle executable images, dependency descriptions, and metadata that move applications across compatible platforms or development environments.
The CAMP metamodel defines a high-level framework that may support multiple languages, platform frameworks, middleware services, and application architecture models in the future. CAMP seems reminiscent of Simple Network Management Protocol (SNMP) or Web Services Distributed Management (WSDM). SNMP requires a Management Information Base (MIB) to effectively manage diverse network device components. The MIB describes details on how to interact with the network platform component and component capabilities.
At this specification development stage, standard platform component metadata schemas are not available for CAMP (beyond existing J2EE/.NET/Ruby configuration options). The CAMP deployment framework is similar to WSDM or WS-Policy, a high level container without concrete definition.
Platform and application portability benefits will require strictly defining platform capabilities (see Database Platform Component Model figure below) and delivering symmetric service provider support. The specification’s example (i.e., Annex C.1.) depicts considerable metadata required to define a common database platform component.
Achieving management interoperability and application portability 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 symmetric, interoperable solutions.
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 Enhancing Cloud Application Portability Across Clouds.