With OpenStack, CloudStack, vendor-developed variants and custom-developed extensions still in a comparatively adolescent state of development, it looks like the open cloud movement is currently competing with itself in the race towards a single "Linux for the cloud" nirvana somewhere.
But a new lower level development could ultimately help push the compass towards future cloud application development in one direction or another.
Under the auspices of the Organisation for the Advancement of Structured Information Standards (OASIS) we now see CloudBees, CloudSoft, Oracle, Rackspace, Red Hat and Software AG announce the CAMP (Cloud Application Management for Platforms) specification to promote what is hoped to be single standard customer-facing API (application programming interface) for access and control of Platform-as-a-Service (PaaS) applications.
While developers have the option to run applications written in the language of their choice on a PaaS platform irrespective of the underlying operating system, IaaS (Infrastructure as a Service) offers a lower level view of the virtual machine, operating system and the language runtimes being deployed in any given environment. With the CAMP API, programmers should be able to run applications on a PaaS with less fear of vendor lock in as the API will be common to any PaaS in use at any moment in time.
This should (in theory) form a virtuous circle where developers are then open to use any number of common software management tools to oversee the operation of their application on the PaaS. Whether programmers wish to implement mobile application optimisation software, release management functions or more fundamental software health and application lifecycle management tools, the gateway here is (theoretically) open due to the single API.
But does CAMP have the potential to meet the interoperability performance standards demanded of it? With a “common development vocabulary” and API capable of working across multiple clouds, CAMP is said to be able to perform“without excessive adaptation” and is compatible with PaaS-aware and PaaS-unaware application development environments, both offline and in the cloud.
CAMP attempts to address the problem of portability across and between clouds by standardising the management API so that porting across different PaaS offerings can occur. But the claim here is substantial and "service assurance through interoperability" almost sounds like a nice advertising catch line.
In practice, real world data flows have a habit of breaking applications in any number of environments. So if CAMP succeeds in “growing the PaaS pie” (to use its originator’s term), then is there a danger of the contents within spilling over if the oven gets too hot.
At first glance there does not appear to be a problem, CAMP operates at a high level to define application interfaces and map application requirements and their components to the precisepower of the platformbeneath. However, it does not extend to be able to define interfaces for any component of application infrastructure outside of PaaS management.
This means that if a platform is constructed to support the operation of a message service bus (for example), then CAMP is not designed to provide a means of posting a message to it. This is not necessarily a “limitation” per se, but it does put some context into the total scope of the technology’s function.
CAMP’s appearance is certainly a welcome development as it sits at what we might consider to be a more granular level than most of the cloud infrastructure. Is this ‘internal’ element of mechanics properly precision-engineered to ensure smooth driving conditions? The early signs are promising.
