Workload Complexities in the Hybrid Cloud Environment

The world is a lot more complicated with the hybrid cloud than it was with a single architecture (if only the world were still so simple!). With the advent of a hybrid cloud world, many more applications and services exist across geographies that have to run. Some workloads may be permanent and need to run constantly, such as an online commerce site or a control system that manages a critical environmental process. Virtualized workloads add another level of complexity. Business services and various application models are added into the mix as well.

In a hybrid cloud environment, your workloads may be running on different clouds, running different kinds of infrastructures using different operating systems. You’re bringing together workloads from different environments that often have to behave as though they’re a unified system.

Operationalizing workloads

What is the connection between workloads and workload management in the cloud? It’s actually at the center of determining whether you have a well performing cloud environment or not. This is true whether you are a service provider offering either a public or private cloud to customers, or if you’re managing an internal private cloud to benefit internal customers and external customers and partners.

You may think that all you have to do is get some automation software (to automatically schedule resources and to perform some other functions associated with allocating resources) and you’re set. When you look at workloads from an operational perspective, it becomes clear that lots of issues need to be taken into account when determining how you create an overall hybrid cloud environment that both performs at a quality level and meets security and governance requirements. This is not a static requirement; from an operational perspective, organizations need to be able to dynamically change workload management based on changing business requirements.

For example, say a workload is now being used within a geography that has different rules for where data must be placed. If the data has to be stored within a country, then that workload has to be managed differently than the same workload running in a country without this type of governance requirement. With fewer restrictions, IT operations is free to move workloads to locations that have the bandwidth or capacity to meet the quality of service required by the business. In fact, the ability to change and move workloads based on business requirements is at the heart of operational issues in the cloud.

APIs: Key to managing cloud workloads

Application programming interfaces (APIs) enable a software product or service to communicate with another product or service. For example, if you’re a software developer who has written a spreadsheet program and you want to allow another developer to add some specialized functions to enhance your application, you can provide the developer with an API that enables him to write to your application. The API specifies how the one application can work together with another one. It provides the rules and the interfaces. The developer doesn’t need to know the nitty-gritty of your application because the API abstracts the way these programs can work together.

An API also provides an abstracted way to exchange data and services. Because of this abstraction, the API can hide things from developers. For example, you don’t want an outside developer to learn the details of your internal security, so those details of the system are hidden. The API allows the developer to execute only the intended task.

As you’ve probably surmised by now, APIs are important for managing workloads in a cloud environment. The Amazon Elastic Compute Cloud environment offers a rich set of APIs that allows customers to build their own workloads on top of Amazon’s compute and storage services. In fact, every company that offers a foundational cloud service such as IaaS, SaaS, and PaaS develops APIs for its customers.

Everything is great as long as you manage your workload within the environment where you created it or where you will deploy it. However, many organizations are beginning to face the fact that different APIs aren’t always compatible. For example, one API may be built to support a 32-bit operating system, and the cloud environment that the developer wants to move the workload to supports a 64-bit implementation. To make the transition from a 32-bit model to a 64-bit model requires extensive programming.

To better understand the complexities of the problem, consider what happens when you create workloads in the Amazon IaaS platform. Here are three common scenarios you might encounter:

Amazon lets you create a set of connections to the network as a security group by assigning a permanent IP (Internet Protocol) address. If you try to connect this public service with a private cloud service, you’ll find incompatibilities at the networking level.

You create a workload for storage on Amazon and a second workload for storage in another public cloud for redundancy. You have a third storage workload running in the private cloud. When changes occur, you don’t have a standard way to manage these three storage services. This situation can allow errors, thus preventing the three storage workloads from functioning as intended.

Cloud APIs are all different. Although Amazon APIs have become a de facto standard, many more APIs have emerged in the market. For example, there is the Open Cloud initiative, the Open Cloud Stack, the IBM Smart Cloud, and the Microsoft Windows Azure market. None of these cloud APIs are compatible with each other.

The question becomes, how do you manage workloads across incompatible environments?

The necessity of a standard workload layer

As you see from the previous example, no standard API allows the developer to work with different cloud models provided by different cloud vendors. What is actually needed is a standard layer that creates compatibility among cloud workloads. In service orientation, the XML model allows for interoperability among business services. There’s no equivalent model for the hybrid cloud.

Of course, you can always find ways to work around complicated problems. For example, in the cellphone market, vendors end up implementing both the U.S. and the European wireless connectivity standard into each phone set. Likewise, in hybrid workload management, companies such as cloud management provider RightScale (www.rightscale.com ), IBM’s Workload Deployer (www.IBM.com ), and BMC’s Control-M (www.BMC.com ) create customizable templates that allow developers to make allowances for the differences in APIs and thus are able to deploy and migrate workloads.

Portability of workloads

Discussing APIs and standards is essential because workload management is fundamental to the operation of the hybrid cloud. In a hybrid cloud environment, being able to move workloads around and optimize them based on the business problem being addressed is critical. Despite the fact that workloads are abstracted, they are built with middleware and operating systems. In addition, workloads must be tuned to perform well in a specific hardware environment. In today’s hybrid computing world, a lot of manual intervention is needed to achieve workload portability. However, we anticipate future standards and well-defined approaches that will make hybrid cloud workload management a reality.

The advent of hybrid computing will lead to the evolution of a new component in cloud computing. The broker of hybrid service workloads will provide a layer that will examine the infrastructure of the underlying cloud-based service and provide a consistent and predictable way to handle different workloads as though they were built the same way. We expect that this hybrid service workload broker will provide the hybrid workload management that the market will demand. When standards evolve, the need for part of this layer will go away, but the broad use of standards takes time.

Managing hybrid workloads

Managing workloads in a hybrid cloud environment requires a set of distinctive steps, including these:

Keeping track of dependencies among specific services, such as Software as a Service, and Business Process as a Services like credit checking services. The management environment needs to manage these relationships.

• Workloads need to be scheduled based on business policy and required dependencies for third-party processes.

• The workloads need to be monitored and optimized based on the company’s service-level requirements.

Governance of workload management is essential for success. The IT organization needs to guarantee that corporate and governmental regulations are adhered to. For example, in the hybrid world, it may be necessary to execute a workload in a particular country. In other situations, some data must be stored within a special secure environment.

For more information about management in the hybrid environment, see Chapter 4.