CAMP 1.0 – An Open API for PaaS Application Management
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
while suspending an applications may be done as in the following example:
POST /<assembly-resource-url> HTTP/1.1
Content-Type: application/vnd.org.example.PaaS +json;type=Xxxxx
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.
Don't see it working out
- 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
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
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?
Shane Hastie on Distributed Agile Teams, Product Ownership and the Agile Manifesto Translation Program
Shane Hastie Apr 17, 2015