Guiding the enterprise into a hybrid cloud model
A comprehensive collection of articles, videos and more, hand-picked by our editors
Cloud computing is a major departure from the traditional relationship between applications and compute or storage...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
resources. Even in virtualized data centers, there normally is a static assignment between an application and a virtual machine, and then from a VM to a specific server. However, in either a public cloud or private cloud, resources are pooled and assigned to applications as needed. This loose coupling between apps and resources creates a new management challenge for providing Quality of Experience, or QoE, for workers or consumers.
This management challenge is complicated by the multiple vendors that make up the infrastructure, hybrid cloud configurations that span multiple cloud platforms, and private clouds that are based on different systems and software or middleware tools. In these cases, consumers often will have to build their own cloud management system to harmonize all their resource and network management options.
Even in cases in which management standards exist for a particular type of resource, vendors normally will extend the standards to differentiate their products and to support the enhanced features those products may offer. In networking, for example, the Simple Network Management Protocol, or SNMP, may define a standard management information base for a type of device, but vendors will almost always extend it. This means that the resources used in a private cloud or hybrid cloud will almost surely require their own management system, and that centralizing cloud management means managing the various management systems, not the devices directly.
Often, the best approach involves open management tools or high-level management platforms.
Integrating high-level open management tools and platforms
Most users are familiar with some high-level open management tools: Hewlett-Packard's OpenView, IBM's Tivoli, CA's Unicenter and Microsoft's System Center, for example. Most of these tools can function as high-level or open management platforms for the cloud, but the work and cost of integrating them will vary depending on how many resources they support out of the box. The vendor supplies most of an enterprise's cloud resources, so that's the starting point for this management platform. An inventory of the lower-level management tools with which the open management system will have to work is essential in plotting out a project to make such a platform cloud-ready.
Open source management tools are cheaper and can be customized to fit your needs, but they could require integration, the customization can be difficult, and you often lack support. The most commonly considered open source packages include Nagios, OpenNMS and Pandora, but users interested in open source cloud management are turning to products specifically designed for the cloud.
Some of these high-level open management tools will have plug-ins or other tools to support management of some public cloud services, but how well these are integrated with the management of local resources will vary. Cloud management platforms often are better designed to support cloud management interfaces and the hybridization of public and private resources. As with open management tools, cloud management platforms are available in commercial and open source form.
OpenNebula and Scalr are two of the most popular open source tools. Red Hat's CloudForms is a hybrid cloud tool that's open source but has support from Red Hat. HP, IBM and Microsoft all offer cloud management through the same platform they use for network and systems management, and there are many vendors -- such as RightScale, enStratus and ServiceMesh -- offering commercial tools.
Companies shouldn't begin to look into the customized integration of management tools to create an open management system for the cloud without extensive research. Virtually all management systems have application program interfaces through which their features can be accessed, and it's possible to develop applications that exercise management control through these APIs. Such development normally is outsourced to organizations with specific management skills, but it can be used on a smaller scale to customize cloud or manager of managers (MOM) platforms to lower-level management interfaces they don't support directly.
Cloud management frameworks based on MOM concepts are a combination of a graphical user interface, a set of mapping and correlation functions, and a collection of management interfaces, some of which are standardized for device or vendor management interfaces and some of which are likely customized by the buyer or an integrator. Some users also write custom applications to perform specific management tasks through these APIs.
Where open management for cloud will fail you
The most common problem with open management through cloud management tools is its lack of visibility down to the lower levels of devices and a general loss of granular control. Thus, it's important to ensure that a cloud management tool will offer proper drill-down from a high-level report to device-level detail before you select one as an open management platform. Otherwise, it's necessary for operations personnel to switch management consoles during normal management and fault isolation and resolution tasks. Doing this lowers productivity and increases the risk of errors -- and management errors can be catastrophic to cloud performance and availability.
Finally, being able to manage the entire cloud from a high to a low level from a single console is most important for organizations that don't naturally segment their operations personnel into network, IT and public cloud. Where such a division exists, high-level cloud management might be responsible only for monitoring overall resource "health," particularly if that health can be expressed in terms of an objective service-level agreement (SLA), even for internal resources. Violations of the SLA then would be referred to the specific group of managers involved, who could then use their own specialized management tools. To make this work, though, the high-level system must be able to isolate the problem to a management jurisdiction -- and in the expanding world of the cloud, that could prove difficult.
About the author
Tom Nolle is president of CIMI Corp., a strategic consulting firm founded in 1982 that specializes in telecommunications and data communications.