singkham - Fotolia
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.
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.