singkham - Fotolia

Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

A CAMP-centric approach to cloud application management

Tom Nolle offers assessment strategies to determine CAMP's potential in a cloud application management project.

In cloud terminology, "cloud application management" can be divided into two distinct categories. The first is a set of tools that are designed to operate across multiple cloud platforms to offer unified deployment and management. The other defines a protocol or API that is standardized across all cloud platforms, thus unifying practices.

This latter category creates a Cloud Application Management Platform (CAMP) by default. Cloud architects and planners need to understand CAMP's potential by assessing CAMP approaches, reviewing the support for a given option, and evaluating how a CAMP strategy would be linked to deployment and management tools.

Every public cloud provider, including Amazon, Google and Microsoft, has standard management APIs to support deploying applications in the cloud. The problem for cloud architects is that they're all different. Private cloud deployments based on cloud stacks also present different management APIs. This complicates the "normal" application deployment and ALM process because every step that's automated must then work through one of several API options. If different management functions are available for different clouds, whole ALM process chains may have to be reviewed for each cloud option, public or private.

One approach to securing standard management in the cloud is the creation of standard APIs to drive management tasks. Some de facto approaches have already emerged in the form of OpenStack and Eucalyptus cloud management tools. These are generally compatible with basic AWS tools. The challenge is that none of these approaches are universal and it seems unlikely that all of the public cloud providers would be induced to adopt one of these current CAM approaches. A formal standard could be helpful, if it's accepted.

The formal standards activity for CAMP is hosted in OASIS. Any CAMP assessment should begin there. OASIS decodes the acronym as "Cloud Application Management for Platforms." In other words, OASIS is not attempting to converge management tools but to provide a single way of managing clouds, regardless of their native management interfaces. CAMP, combined with cloud deployment tools, to creates a single management interface.

Be sure you understand the current state of CAMP support before committing to a CAMP-centric strategy.

Because OpenStack was the target of the predecessor project, Solum, it's likely that OASIS CAMP would satisfy the private cloud needs of users. However, cloud providers who adopt OpenStack may feel, as Amazon does, that a unified management protocol that could support portability of cloud deployment across providers increases their own risk of customer churn. This concern could inhibit adoption of CAMP by even OpenStack-based public clouds, and perhaps even rule it out for clouds like Amazon. However, it's possible that Amazon and others would be forced to adopt CAMP if it became highly successful in the OpenStack world.

Be sure you understand the current state of CAMP support before committing to a CAMP-centric strategy. OASIS CAMP is more an assessment goal for now. It's an opportunity to change cloud management strategies to something more standardized if significant support develops for it. The best way to assess CAMP in the short term is to see how it's being accepted in the OpenStack world. Since CAMP was built from an OpenStack-friendly ALM model, OpenStack is the path of least resistance, in terms of adoption. If CAMP isn't advancing in OpenStack, then it likely won't advance elsewhere.

The most complicated issue with CAMP-centric cloud application management is whether or not to plan application deployment purely in CAM terms. In most cases today, CAM is treated as a deployment option within a broader DevOps strategy. OASIS' Topology and Orchestration Specification for Cloud Applications (TOSCA) may represent the "standard" approach to cloud-centric DevOps, in which case TOSCA and CAMP should be evaluated in parallel.

TOSCA and Linked Universal Service Description Language (USDL) have been used in combination in research projects. Together, they can be used to describe cloud services and even create cloud self-service portals. In theory, TOSCA could drive CAMP interfaces to deploy cloud elements, and this combination could generate at least a layer of cloud application management that is completely standardized. What is less certain is whether such a combination could provide the features needed to describe a complete hybrid cloud deployment. It is also questionable whether the combination could provide support for all the critical ALM steps.

ALM is the weak link in CAMP. As a cloud management protocol specification, it starts at the bottom of the stack of features needed to create cloud-ready ALM. Tools built to provide more complete DevOps support could, if made to work with multiple cloud management interfaces, lessen the value of CAMP.  Even integration with OASIS TOSCA (not yet realized) might not help. It follows that the way CAMP might fit in an ALM strategy will be the critical factor in establishing CAMP's value.

Companies who see cloud deployment primarily as an element of ALM, and who have a commitment to a commercial or open-source DevOps tool, should ask whether there's a path to supporting multiple clouds through their current tools before they think about a CAMP-centric strategy. Those who don't see a specific advantage in linking ALM tools to cloud deployment may find the cloud portability promise of CAMP a compelling benefit. In this case, watch the progress of CAMP and adopt it when it's clear it will be broadly useful.

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Do you think OASIS CAMP will eventually become a standard for app management?
Every PaaS cloud has it's own, REST-based, application management API. This API is usually driven by both a web-based console and a command-line tool. There is nothing particularly valuable these APIs. No one ever selected, for example, Heroku over Engine Yard because Heroku's application management API was so much better. The fact that all these APIs are different makes it harder to use multiple clouds or switch between clouds. This pain point hurts overall PaaS adoption. By agreeing to standardize these commodity APIs, PaaS vendors can "grow the pie" of the PaaS marketplace without impacting their differentiated added value (i.e. they can keep doing what makes them special). The value of a PaaS cloud lies in (a) the correspondence between the abstraction level provided by that cloud and the needs of its customer base, and (b) the richness and diversity of its service ecosystem. Attempting to lock-in customers with proprietary APIs is both short-sighted and, if history is any guide, ultimately doomed to failure. 
I would think so brought by IBM a plug-in will help drive the quality of the standard moves apps between cloud too
Lots of 'IF statements' in the article, and the article's final bottom line is "watch the progress of CAMP and adopt it when it's clear it will be broadly useful." For planning purposes, would be good to understand when CAMP will be widely support across target environments.