CAMP 1.0 – An Open API for PaaS Application Management

| by Abel Avram Follow 11 Followers on Aug 31, 2012. Estimated reading time: 2 minutes |

Several companies including Oracle, Rackspace, Red Hat and CloudBees have proposed an API for PaaS application management. The API allows developers to manage applications within and across various PaaS that will implement the specification without having any knowledge of the underlying cloud infrastructure.

CloudBees, Cloudsoft Corporation, Huawei, Oracle, Rackspace, Red Hat, and Software AG have announced a new PaaS management API called Cloud Application Management for Platforms (CAMP). The API can be used by cloud service providers and users to create applications for managing resources in the cloud. The initiators start from the idea that cloud users should not deal with low-level resources such as virtual machines, storage or networking, but rather should be able to access high-level resources, such as applications and their components. Also, users should be able to access PaaS services from different vendors using a single management console, and they should be able to easily transfer resources between different clouds.

CAMP’s API is built on top of HTTP/1.1, includes a RESTful binding and uses JSON for transferring resources. CAMP functionality is to be provided as plugins to an Application Development Environment (ADE) or an Application Management System, allowing developers to create their application with ADE then upload, deploy and instantiate it within the cloud of their choice.

CAMP defines [PDF] a number of resources including cloud platform, platform components, application, and application components. A cloud platform is the entire PaaS seen as a resource accessed though CAMP, while a platform component may be various services offered. CAMP currently defines only one such service, namely a Database-as-a-Service (DBaaS).

One of the main resources is application, and CAMP offers interfaces for dealing with it throughout its entire life cycle depicted below:


An application is instantiated using a POST command, as in the following request-response sequence:

POST /paas/asm_template/1 HTTP/1.1

HTTP/1.1 201 Created
Content-Type: ...
Content-Length: ...

while suspending an applications may be done as in the following example:

POST /<assembly-resource-url> HTTP/1.1
Content-Type: application/ +json;type=Xxxxx
Content-Length: ...

{"new_state": "suspend"}

HTTP/1.1 200 OK

CAMP has been submitted to OASIS for standardization, including a proposed charter (PDF) for the technical committee that is supposed to adopt it as a standard in 18 months. Oracle is the most involved company in the creation of CAMP with 7 out of 14 specification authors.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Don't see it working out by Eugene Tolmachev

- There's already an API to manage all the parametrization and at least 2 leading providers implement it: Amazon WebServices (it's one of the Rackspace selling points!)

- On the opposite end of the cloud deployment spectrum, there's are high-level package deployment services, like Azure and Heroku

While the API itself seems simple, I could see the package authorization, URI standardization, versioning, etc. quickly becoming a hurdle no one will want to deal with.

Re: Don't see it working out by Gilbert Pilz

I'm not sure what you mean by an "parametrization".

As for Azure and Heroku, yes they have APIs that allow you to deploy, start, stop, restart, etc. your application as does Engine Yard, Google, Cloud Foundry, etc. The point is that all these APIs are different and there really isn't any point in them being that way; it's not like anybody ever said "I prefer to use FooCloud because their application management APIs are so cool."

As for your other concerns: security and versioning are difficult (though not impossible) but I don't see why we would need to standardize URIs.

Re: Don't see it working out by Eugene Tolmachev

If you look a the API, it has two aspects: VM management (provisioning/modification specification, i.e. parametrization) and package deployment (with requirements specification).
For the former, AWS API looks well thought out and very comprehensive (and I don't see Amazon in the CAMP camp).
For the latter, URIs would have to be standardized in order to provision correct dependencies (as those are identified by URIs). The scope of the standard can vary, but narrow it down too much - and it's too burdensome for the consumer, too much - and it's too unwieldy for the vendors. Basically, how portable are my packages?
And yes, I'd say API (or modus operandi in general) along with the price would be the top two factors in choosing a cloud provider. That's how I pick, anyways.
What are your top two factors?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you