Friday Feb 28, 2014

Second CAMP 1.1 Public Review

Today OASIS announced the second Public Review of the Cloud Application Management for Platforms (CAMP) specification. The CAMP Technical Committee considers its work on this version (1.1) to be finished. Baring any substantive changes needed to address review comments and pending the fulfillment of the implementation requirements in the charter, this is the draft that will be approved as Committee Specification and, hopefully, become an OASIS Standard. If you have an interest in this space, you might want to review this draft and, if you have any concerns or issues, comment via the public mailing list.

To keep from rehashing previous material, I'll direct you to the blog entries on the original announcement and first PR and focus on some of the major changes in this version of the specification.

One-step deployment process

Previous drafts of the spec defined a two-step process to deploy an application: (1) POST a PDP or Plan file to the Platform resource to create an Assembly Template resource, (2) POST to this Assembly Template resource to instantiate an application (represented by an Assembly resource). One of the comments the TC received on the first PR was something along the lines of "What were you thinking? No commercial PaaS offering requires such a two-step process." Point taken, so CAMP now supports a single-step deployment process in which the client simply POSTs a PDP or a Plan file to the assemblies resource collection which, in the success case, results in the creation of a new application (still represented by an assembly resource).

Resource model simplification

Another issue with the first PR draft was the complexity of the resource model. Components were separated into "Application" and "Platform" components". Every component had a corresponding template,  thus Application Component Template, Platform Component Template, etc., and each of these had corresponding Requirement and Capabilities resources. The whole thing was a bit dizzying, even to those accustomed to the spec. To address this the TC simplified the resource model by removing templates, requirements, and capabilities. There are now three main CAMP resources: assembly resources, which represents instantiated applications; component resources, which represent the components of an application (no more split between "application" and "platform" components); and service resources, which represents the services offered by the underlying platform. The various metadata resources that support the advertisement and discovery of the types, extensions, etc. supported by the platform are largely unchanged from the first PR draft.

Resource type inheritance

CAMP resources are strongly typed and extensible. This version of the spec adds an inheritance model that allows providers to define resource types that inherit the attributes and behavior of one or more other resource types. For example, a provider could define a database component resource that inherits from the CAMP-defined component resource and adds the required attributes 'database_uri' and 'cache_size'. This new resource type could be used anywhere CAMP specifies the use of a component resource. The metadata resources used to describe resource types have been updated to include these inheritance relationships and eliminate redundant information.

The plan resource

CAMP Plans provide "a description of the artifacts that make up an application, the services that are required to execute or utilize those artifacts, and the relationship of the artifacts to those services". In this version of the spec, Plans can be represented as JSON resources as well as YAML files. Plan resources accomplish the function that the old template, requirement, and capability resources attempted to fulfill; namely allowing developers and admins to wire application artifacts to the services needed to support those artifacts. This is particularly useful in cases where there isn't a match between the requirements described in the initial Plan file and the services offered by the target platform. Plan resources can be used to create an application in the same way that Plan files are used - by POSTing a reference to the Plan to the assemblies resource collection.

For an example of what a CAMP 1.1 system would look like, I suggest checking out the Solum project, which was designed based on the concepts expressed in the CAMP spec. In addition to this there is the proof-of-concept implementation, nCAMP.

Monday Aug 19, 2013

CAMP 1.1 Public Review Announced

The OASIS CAMP TC has released the first Public Review draft of the CAMP 1.1 specification. Here are some of the highlights:

  • The details of the Platform Deployment Package (PDP) and the Deployment Plan (DP) have been worked out. A PDP can be a ZIP, TAR, or TGZ that contains a Deployment Plan and whatever else the application needs (code, data, configuration, etc.). A Deployment Plan is a YAML file that describes the stuff in the PDP and its relationships to the underlying platform services. Manifests and signatures are handled in the same way that OVF handles them.
  • A bunch of metadata resources have been added to the resource model. Due to the minimal nature of CAMP, it is expected that providers will extend the spec by adding new resources, adding attributes to existing resources, adding operations to resources, etc. These new metadata resources normalize the way providers advertise and consumers discover those extensions which, obviously, helps with interoperability.
  • All the normative statements in the spec have been identified and indexed. This makes it easier for implementers to figure out what they need to do to conform to the spec as well as lays the groundwork for the forthcoming Test Assertions specification.

There still a number of rough edges and unfinished areas. For example, the nature and functioning of the Capabilities resources are still undecided as is the thorny issue of how much (or how little) to say about authentication mechanisms. With hard work and a little luck the TC should have these issues (and any issues raised during this Public Review) resolved in time for the second Public Review planned for late October.

On a private note, I have to mention that participating in the OASIS CAMP TC has been a blast. The level of professionalism, mutual respect, and willingness to both listen and compromise have made the CAMP TC the best working group I've ever been involved in.

Thursday Aug 30, 2012

Cloud Application Management for Platforms

Today Oracle, along with CloudBees, Cloudsoft, Huawei, Rackspace, Red Hat, and Software AG, published the Cloud Application Management for Platforms (CAMP) specification. This spec deals with application management in the context of PaaS. It defines a model (consisting of a set resources and their relationships), a REST-based API for manipulating that model, and a packaging format for getting applications (and their attendant metadata) into and out of the platform.

My colleague, Mark Carlson, has already provided an excellent writeup on the spec here. The following, additional points bear emphasizing:

  • CAMP is language, framework and platform neutral; it should be equally applicable to the task of deploying and managing Ruby on Rails applications as Java/Spring applications (as Node.js applications, etc.)
  • CAMP only covers the interactions between a Cloud Consumer and a Cloud Provider (using the definitions of these terms provided in the NIST Cloud Computing Reference Architecture). The internal APIs used by the Cloud Provider to, for example, deploy additional platform services (e.g. a new message queuing service) are out of CAMP's scope.
  • CAMP supports the management of the entire lifecycle of the application (e.g. start/stop, suspend/resume, etc.) not just the deployment of the components that make up the application.
  • Complexity is the antithesis of interoperability. One of CAMP's goals is to be as broadly interoperable as possible. To this end, the authors of CAMP tried to "make things as simple as possible, but no simpler". For example, JSON is the only serialization format used in the spec (although Providers can extend this to support additional serialization formats such as XML). It remains to be seen whether we can preserve this simplicity as the spec is processed by OASIS. So far, those who have indicated an interest in collaborating on the spec seem to be of a like mind with regards to the need for simplicity.
  • The flip side to simplicity is the knowledge that you undoubtedly missed something that is important to someone. To make up for this, CAMP is designed to be extensible. The idea is to ship what we know will work, allow implementers to extend the spec, then re-factor the spec to incorporate the most popular extensions.

Anyone interested in this effort, particularly those of you using PaaS-level services, is encouraged to join the forthcoming OASIS TC. As you may have noticed, CAMP is a bit of a departure from some of the more monolithic management standards that have preceded it. The idea is to develop simple, discrete standards targeted to address specific interoperability and portability problems and tie these standards together with common patterns based on REST and HATEOAS. I'm excited to see how this idea plays out.

Friday Nov 12, 2010

Assertion Based Testing in the WS-I Profiles

[Read More]

Monday Feb 16, 2009

The Problem With Wrapped Notifications

[Read More]

Gilbert Pilz works in the Middleware Standards group at Oracle.


« July 2016