The cloud creates, quite literally, another dimension in application lifecycle management. At every stage, planners,...
architects and developers have to reflect cloud-enablement into their plans, from testing to deployment to certification. This requires some formal link between the ALM processes and the cloud, over which deployment and status information can be exchanged. That link is created by a Cloud Application Management Platform (CAMP).
RESTful APIs are a popular strategy for CAMP, but architects and planners and even developers have to consider the CAMP model that the APIs represent and ensure that CAMP integration is sustained through the traditional application lifecycle management (ALM) tools. It is also important not to forget the question of "return status" and to beware of the issue of standardization of CAMP across cloud options.
The fundamental goal of cloud application management is to deploy applications. Of course, deploy and applications are not precise terms. An application is an ordered structure of components that deploy to function as a unit. Since multi-component applications are the rule these days, implicit in a CAM model is an application component model, so the first step is to decide just what that model is and what CAM APIs represent as resources.
With RESTful APIs, this may not be as easy as it sounds because they represent stateless resources and it's easy to fall into stateful thinking on decoding application models. An application is a hierarchy. Application > Component Set > Deployment Instructions. Since cloud application management is essentially a form of DevOps, the first question is whether the CAM software recognizes applications or deployable components.
Component-level and application-level CAM
Application-level RESTful CAM options would recognize transactions at the application level and within applications at the component level. Since RESTful processes do not associate applications and components, developers have to be able to do that themselves. This means that they will need to initiate an application creation request, save the unique ID the CAM API will presumably return and then use that ID to populate the model with components. When that is done, the developer will also get unique IDs for components added, and these will also have to be saved.
Component-level CAM doesn't get involved with how components bind into applications, and while this may seem to require more from the user, it may generate less work. Most companies are deploying hybrid cloud applications and using their own DevOps and integration tools. An application-level CAM service is much more "DevOps-like" and also has more points of integration with lifecycle management processes. Integrating this kind of tool into the company's ALM may be fairly complex. On the other hand, component-level CAM is just about deployment and is usually easy to link with DevOps and ALM tools.
When companies plan to exercise application-level CAM APIs, they need to consider structuring their own DevOps and ALM processes to enforce a strict application and component hierarchy. For places where they have application-level CAM tools, developers can wrap those tools in an application-level structure within the company's process flow. That way, where only component-level CAM is available, developers can define the specific application-level tools themselves. When doing so, consider standardizing the information available per component and at the application level across all CAM sources and with the company's internal components. This will create a common framework for management, security and compliance.
One of the challenges of RESTful APIs is that they presume a client-server poll model of information exchange, which makes them unsuitable to pass extemporaneous status changes back to the requestor. The more architected the CAM service set is, the more difficult it would be to integrate the status information from CAM back to the application-level QoE management. There are two choices here: Poll regularly or separate management events from CAM.
It's easy to construct a RESTful CAM service to obtain status. Most CAM tools will have a mechanism to provide it on request. It may be a challenge, however, to know when to make the request and whether the response is authoritative for a company's QoE purposes. There is also the risk of creating a virtual denial-of-service attack by flooding CAM with status requests.
Beware of overload
The "authoritative" issue may not be obvious. When developers check for status at fixed points in a cloud workflow, they'll only be able to take specific remedial action at those points. If a status change occurs after a positive check has been completed, they'll go forward presuming the work can be processed even if future status information proves otherwise. In fact, architects often introduce multiple status checks to granularly detect problems. This can explode the use of status requests to the point where they overload CAM.
Where the CAM interfaces support it, it's probably better to have status changes pushed to a specified management process. While this makes status reports asynchronous to CAM activity as well as workflows on the deployed components, it's ultimately easier to integrate these status reports with workflows. At the worst, the architect can set context variables within the service bus that BPEL can test. Since the architects are defining the process to which cloud status is pushed, they can define what's done there.
Having an explicitly defined application and component model in the company's DevOps and ALM tools -- and even integrated into BPEL -- combined with pushed status information on cloud component status can help solve another problem: CAM portability. Most public cloud providers have their own CAM APIs, and while there is an emerging CAMP standard, it's far from universal. If you presume your own models will be used, you can adapt CAM APIs from multiple cloud providers to those models. This makes the higher-level tools and processes you define more independent of your cloud choice.
Cloud application management is evolving as the cloud evolves, and there may be no area as likely to present architects and planners with dramatic changes. Thus, it is critical to monitor developments and standards both from the software side and the cloud services side. New features and capabilities won't redefine the issues, but they may redefine the solutions.
Learn how to make ALM more agile
Go deeper into ALM security
Read up on mobile ALM
Dig Deeper on Cloud application development and deployment
Tom Nolle asks:
What cloud app management challenges have you run into?
0 ResponsesJoin the Discussion