Application planners, architects and operations managers all know that deployment of applications today is complicated…
Step 2 of 2:
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
by application componentization, workflow steering and cloud adoption. Most use tools like DevOps to facilitate deployment, but hybrid clouds can defeat even those tools. To understand hybrid cloud management, understand the challenges hybrid clouds pose for even modern management tools, think of application deployment and redeployment in layers, and recognize that full management automation is the final goal, so it’s critical to know whether your hybrid cloud management approach will lead there.
The deployment of an application in a data center is usually driven by a script- or model-based tool like DevOps that automates the steps to be taken. Because these steps typically involve setup functions, this could be called the “configuration” era. Experience has shown that without some sort of deployment automation there’s a high risk of errors and application failures, and even security or compliance problems. With the right DevOps tools, operations personnel can deploy even complex applications correctly.
When cloud computing came along, the deployment process had to adapt to the use of external resources, usually by accommodating the “cloud management system” interface. Although this is different from data center deployment, it did not prove difficult to accommodate the changes that public cloud deployment brought, and for many users this means that “hybrid cloud” won’t pose a threat. Cloud DevOps evolved from data center DevOps.
Most cloud “configuration” management today is based on scripts, because data center operations personnel naturally relate cloud deployment to a series of steps to be taken. Where configuration-based cloud management starts to show stress cracks is where the configurations of applications change. In pure public cloud applications, accommodating failures or excess load by instantiating new components could be accommodated in the configuration model of cloud management. For hybrid clouds, that’s more difficult.
Hybrid clouds can be based on static or dynamic positioning models. In the former, application components are either assigned to the cloud or the data center, and they tend to stay where they’re placed. This model can be managed using traditional tools and practices, providing that the differences between data center and cloud deployment can be described as a difference in management interfaces.
Dynamic hybrids move application components around, replicating or destroying copies to respond to load changes or replacing components that have failed. When component instantiations stay within either the data center or the public cloud, traditional DevOps practices can still be applied. But application components and workflows can move across the public-cloud-to-data-center boundary, and different deployment and connection rules apply on each side of that border.
In the limiting case, a dynamic hybrid cloud is a single resource pool of both public cloud and data center hosting points, allocated as needed. The challenges of deploying (and redeploying) components in this hybrid model are similar to the problems of building network services from hosted features, a requirement for the new Network Functions Virtualization activity within ETSI. There, the deployment and management of features is called orchestration.
As noted earlier, configuration and deployment tools used in the data center and for static hybrid cloud models are often based on modernized scripting languages, adapted to provide access to CMS interfaces. In the dynamic hybrid cloud model, orchestration tools appear to be evolving toward the declarative-model-based approach. The international standard for cloud management, Topology and Orchestration Specification for Cloud Applications (OASIS TOSCA) is a declarative model. Because these models specify an end-state, they can accommodate redeployment in response to load change or failures more easily.
Declarative models for dynamic clouds seem to be evolving toward a modeling approach called intent modeling, where a model describes the goal (“intent”) of a given process rather than the specific steps needed to implement it. When used in cloud deployment, intent modeling would describe the application configuration, including deployment constraints and connections. This model would then be decomposed to create the application.
Although declarative models are a strong step toward supporting dynamic hybrid cloud management, they may not be enough. The challenge with dynamic clouds lies both in the number of conditions that could occur (failures anywhere, changes in load or QoE expectations, etc.) and the number of possible valid configurations (in-cloud, in-data-center, mixed). The ultimate goal of hybrid cloud management is full management automation, and this will almost surely require a merging of orchestration modeling and event-driven management.
While NFV is an initiative driven by network operators, some cloud providers are already exploring how it could improve cloud operations, and even some enterprises are tracking NFV’s progress. What is lacking so far in NFV is a specific standard for integrating events into service models. Some NFV implementations integrate event management into declarative models, and so can define a complete application lifecycle.
Another lesson of NFV is that complete application lifecycle automation isn’t likely to be achieved; certainly not in the near term and perhaps not even longer term. When an application fault cannot be remedied, for example, there is almost surely an escalation and notification task to be carried out. Management automation tools must be able to integrate with legacy processes like email or IM notifications, and also generate work orders to dispatch technicians to fix or replace a device like a server.
It would be easy in a situation like this to let hybrid cloud goals outrun management technology. To avoid that, try to focus early hybrid cloud management on declarative modeling rather than on scripting, or use a combination of the two that links scripts to very specific lifecycle conditions. At the same time, review the progress of TOSCA and NFV implementations because these activities are aligned most directly with full management automation goals. Hybrid cloud management will get to that happy state eventually, and the benefits in stability and efficiency will be significant enough that you won’t want to miss out.
Tackling hybrid cloud management issues
A look at one hybrid cloud management tool