Cloud Computing on Ulitzer

I had a great conversation with a well-respected colleague of mine today. We discussed what it will take to deliver on the promise of hybrid clouds. We both agreed that a significant amount of intelligence needs to be added to the current architecture of Cloud Computing in order to even begin to deliver on the promise of making a hybrid cloud a reality. My colleague seems to think it will take the industry another decade to really make these technologies as ubiquitous as IP and the Internet itself. I'm of the opinion that we can get there faster if the industry collaboratively focuses on some of the major hurdles.

The Hybrid Cloud
A hybrid cloud is one in which a workload can theoretically move seamlessly between a  private cloud and a public cloud. Hybrid clouds offer the panacea that you can have protected workloads internally, capacity-driven workloads in an on-demand public cloud, and the ability to shift some of those workloads between the two, depending on requirements.

For the last few years, from about 2008 on, various individuals and organizations have been purporting the benefits of a hybrid cloud architecture. On paper, hybrid clouds look wonderful. But there is a disconnect between the paper diagram and the reality of the situation.

It appears as though many of the supposed cloud experts involved in the mass hysteria of hybrid clouds have yet to dig deeply into the technical limitations of modern workload portability. While the concept of a hybrid cloud, and the ability to shift workloads from one datacenter to another sounds fantastic, there is a significant gap between the architecture of the existing technology and the business requirements.

The Missing Links
An exhaustive list of all the obstacles involved in hybrid clouds is not our intention. Generally speaking, there are successful implementations of both private and public clouds already. Yet, at this time, the major obstacle of bridging the two into a hybrid cloud is workload mobility.

Workload mobility is what allows the two cloud types to talk to each other, for lack of a better term. Workload mobility can be accomplished in several different ways. A workload can be migrated offline or online, it can be the entire operating system and application stack, or it could be just the application. A single workload may include multiple instances of operating systems and applications or it may be a single entity.

Which aspects of  workload mobility get implemented on a cloud-by-cloud basis are left up to the designers and owners of each cloud. Regardless of the implementation details, the private cloud must have a means of offloading a workload to a public cloud and/or vice versa. The case may also exist for workload mobility between two public clouds. It is generally taken for granted in many hybrid cloud architectural designs that this capability already exists, but the technology to deliver workload mobility in today's hybrid cloud is actually quite limited.

To some extent, workload mobility does exist. But the existing workload mobility was designed to be utilized within a single datacenter, or within a single network. Hybrid clouds require that a workload, usually a virtual machine itself, move outside the datacenter, usually over a WAN to another datacenter. While this sort of workload mobility can be accomplished on a limited basis today, the existing technology is not designed to support commonplace and well-managed mobility of workloads across the WAN.

For the purpose of this article, the workload is assumed to include access to the data that the workload requires. Every aspect of shifting the workload from one location, or one cloud, to another, should include the same qualifications for the workload's respective data. To effectively accomplish every day workload mobility across the WAN, there are several aspects of workload mobility that must be addressed:

• Workload delivery guarantee - not just a simple Ack (Acknowledgement Packet)
• Workload mobility Quality of Service (QoS)
• Workload Security & Compliance

Workload Delivery Guarantee
Delivery guarantee does not just refer to the successful move of a workload, the ability to fail back if the move is unsuccessful, or the ability to acknowledge its success. Workload delivery guarantee requires that there is some method of planning ahead, before the workload migration begins, to ensure the timely arrival of the workload. In the interest of time, it also requires that there be a predetermined time frame for the workload to arrive at its new destination. Since this time frame should be predetermined, it infers that the workload should be made aware of its Estimated Time of Migration (ETM). Additionally, based on the time estimate, the workload should have the opportunity to act accordingly, prepare itself, prior to the activation of the migration process.

Workload Mobility QoS
The Quality of Service aspect of workload mobility is tied closely to the delivery guarantee. QoS is a method of organizing the priority of network traffic, and it is required at the workload level in the same way that network QoS is necessary at the packet level. Without some means of determining the priority of workloads during migration, it would be very difficult to offer any sort of ETM prior to or during the actual migration process.

It is also important to bear in mind that workload mobility QoS is not directly attributed to the relative importance of the workload that's migrating, although that may often be the case. For example, the QoS level assigned to the migration of a particular workload may be higher or lower than the processor priority, or uptime priority assigned to the workload itself.

Workload Security & Compliance
Security and compliance are becoming increasingly important as more regulatory bodies scrutinize how business is done with respect to technology. Contrary to what some technology purists seem to believe, almost every business has some sort of regulatory restrictions on it. This includes PCI Compliance for credit card and retail transactions and financial compliance for every business that files its taxes or keeps its records electronically. To claim that security and compliance are only issues for major financial, federal, or health related industries just shows a lack of business acumen on the part of some technologists.

Having established the necessity for compliance with hundreds of regulatory bodies, what has not been clearly established are methods of ensuring compliance during workload migrations from one cloud to another.

What Needs To Be Done
The industry really needs to collaborate to address the above issues, and several others. Workload mobility is the cornerstone of hybrid clouds, and right now, that capability is extremely limited at best.

The most obvious work needs to be done at the network layer. This includes integration with the virtualization layer, as the virtualization layer is almost always a critical component of workload mobility. Above that, there is optional work to be done at the operating system and application layers, to further facilitate the transparency of migrating workloads inter-cloud.

The enhancements required at the network layer are the most critical at this juncture. The current level of network awareness for workload mobility is akin to an aviation system that only has local air traffic control, and no communication between cities. Planes would take off and land in whatever order they are ready to go or arrive. At some point, too many planes would be waiting to arrive at a single city because no planning was done ahead of time, and they start to run out of gas in the air, or have to request priority clearance to land in front of other planes that were expecting to be on the ground shortly. Most of the time, things would get sorted out, every now and then, we'd lose a plane. But even when things worked out, it would not provide any sort of reliable flight times.

The need to increase the integration with the virtualization layer is a natural extension of the network layer. In the above analogy, air traffic control needs to be able to communicate to the plane its expected departure and arrival times before it leaves the gate. There also needs to be a means of ensuring that those times remain accurate, and a method of notifying the plane once it has taken off if there is an emergency that requires it to take action. There is no guarantee that the primary, intended server or network connection will be available from start to finish.

The extra mile is integration with operating systems and applications. This provides the ability to not only update the wrapper that holds the workload, but also the application performing the work and the operating system supporting it (though I conjecture we are not far off from those becoming integrated, as well). This is the equivalent of the plane's captain being able to communicate with the flight crew and the passengers in the cabin. Everyone can prepare for how long the flight will be, and can be updated if there are any changes to their status.

The issues surrounding security and compliance will need to be addressed at all the layers of existing architectural models. Most systems have traditionally been designed to be held in a secured environment, with the onus of security placed on exogenous utilities and appliances. That paradigm has to shift some, as the workloads themselves will need to maintain a state of security during migration. Depending on the implementation, that state of security can optionally be maintained when not migrating, adding to the overall benefits of the additional architecture. Much like wearing your seatbelt in the plane while it is still parked at the gate.

In the coming years, we will undoubtedly be hearing from some of the industry leaders, and probably some emerging ones, about technologies they are developing to address these needs. Currently hybrid clouds trail the airline industry in their ability to transport workloads effectively. With proper consideration and collaboration hybrid clouds may offer the equivalent of commercial flights to the moon in the next several years. It is safe to assume that there are many unforeseen needs that will arise along the way and that will create entirely new markets for Cloud Computing technologies.