The great paradigm shift of cloud computing is not self-service...

There has been significant discussion over the short life of the term "cloud computing" about how little it differs from concepts like managed hosting and ASPs. And there is some truth to these observations; if you really look closely, what are the key differences between EC2 and a more traditional managed hosting provider? Some would say multi-tenancy, self-service and pay-per-use (including billing and elastic capacity). With specific regard to EC2, I would tend to agree.

(I would also hasten to point out that Amazon provides some very PaaS-like services in conjunction with EC2, such as Simple Queuing Service (SQS) and SimpleDB.)

However, if this is the great "paradigm shift" of cloud computing, as offered by smart people like Krishnan Subramanian of CloudAve, then let me offer that these basic extensions to existing hosting models will be peanuts next to a shift that will create one of the most significant market opportunities since the explosive growth of the Internet itself. I'm not dealing in hyperbole here; I honestly believe that there is a clear evolutionary step to the cloud occurring well after stand-alone self-service clouds are mainstream (which they arguably are today) that will inspire massive innovation.

That game changing technology disruption will be the federation of disparate clouds, and the distribution of software, data and billing across commercial and private cloud boundaries. In other words, the introduction of secure, reliable workload mobility in an extension of the Internet itself--an "Intercloud", so to speak.

Workload mobility is one of the key innovations of the virtual server world (though it borrowed heavily from its technical ancestry). Technologies like VMotion and other live migration technologies allow system administrators to move running workloads from one machine to another, but today they are generally limited to one subnet.

However, expand the reach of VM motion to cross not only subnet boundaries, but even organizational boundaries, and you get an interesting new world of possibilities. Some of these have been anticipated for some time, but as I talk to more and more people about what could happen here, more and more use cases crop up. For example:

• Follow the Sun: Move workloads to where they are being most utilized at a given time, usually the "day" side of the planet.
• Follow the Moon: Move workloads to where power is cheapest, usually the "night" side of the planet.
• Follow the Law: Move workloads to where the legal and regulatory environment is optimal for the task being executed or the data being stored.
• Optimize Latency: Move workloads to where network routing is optimized for a system of components.
• Optimize Utilization: Move workloads to where the optimal use of compute and/or storage utilization is achieved.
• Optimize Cost: Move workloads to where the cost of computing is as cheap as possible for the workload at hand.

There must be several, perhaps even dozens, of ideas workload mobility would trigger for entrepreneurs and established service providers alike beyond these. I won't deign to have thought through all of the possibilities. The truth is, though, we will probably end up creating complex assemblies of basic sets of policies, mixing and matching as required to meet service levels.

To get to this level of workload mobility, four key areas need to be addressed:

• The mechanism behind workload mobility itself. We've got a great headstart from the likes of VMWare VMotion, but there needs to be more motion aware infrastructure to make this happen ubiquitously. For example, how do you handle what I like to call impedence mismatches between different infrastructure providers, such as one using AMIs and another kvm guest images?
• Integrated and ubiquitous security and control mechanisms. Security for the obvious reasons, but giving the illusion of control is a big part of the workload mobility story. To the owner of the workloads, they should always have the illusion that they are running in their own data center, regardless of where the workload is actually running--though they should control that too.
• Service Level Automation. This is a critical aspect of trust, perhaps the most illusive enterprise requirement in the cloud today. Define service levels at least in part in terms that automation systems can use to tweak elasticity, availability and resource consumption. That automation, in turn, guarantees within reason that customer service levels will be constantly adhered to. Without service level automation across organizational boundaries, it will be impossible to trust systems that become distributed among multiple providers.
• Integration and interoperability protocols and services. We long ago left the world in which production software can be moved around in units called "applications". Almost any system today is comprised of multiple end user applications and back-end services that must coordinate to complete their respective functions. This does not even take into account the management backplane that exists to support those complex systems, that also must coordinate across the same organizational boundaries. All of this has to be available on the shared network in which workload is mobile. If we want workload to be mobile across the Internet, then it must exist as protocols or services on the Internet itself.

The final step of the cloud computing maturity model requires that these requirements be addressed. There is some debate about from what part of the compute landscape these services should be delivered, and how the various "impedence mismatches" of disparate cloud platforms will be handled (or even if they can be handled). Of course, I believe that the network will play a major role, but others see options in pure server software or virtual appliance implementations.

Any way you cut it, though, if you think self-service changed computing and created opportunities, wait until you see the "Intercloud".

[Patricia Seybold]

James,

Good points! I like your four areas to be addresssed for workload mobility and INTER-Cloud computing. In particular, I agree that control is essential. We don't want our mobile workloads to suffer from the same fate that befell investors in Madoff's fund. It "looks" like it's performing great, but it isn't actually delivering the reported returns!

I THINK that the last three of your four bullets can be addressed, at least in part, by CohesiveFT's VPN-Cubed. Have you taken a look?

[jamesurquhart]

Thank you for your kind comments.

I am indeed aware of CohesiveFT's VPN-Cubed and wrote about it on the earlier blog (see http://blog.jamesurquhart.com/2008/10/why-i-think-cohesivefts-vpn-cubed.html).

It is a very innovative solution, though I have always wondered why the network doesn't allow dynamic assignment of VPNs directly to the workloads (in this case, VMs). For now, though, I am a big fan of what CohesiveFT has done.

James

[TheVirtualDC]

James,

Great post. A few things to address in your specific points:

1) VMware is actually doing quite a bit to address incompatibilities between workloads and infrastructure, primarily through vApp and vCloud (and OVF for transcoding as needed, to some extent). And by opening up APIs for both of these, they're doing an excellent job, IMO, with allowing infrastructure providers to be part of the vCloud mobility. I think we're still a ways off but they're taking the baby steps necessary to make this a reality in the not-too-distant-future. vApp should also help address the back-end bundling requirements of VM dependencies.

2) Despite the above, vMotion still has some severe limitations with infrastructure, primarily the network. Moving live images outside a vCenter domain (which means outside the data center for all intents and purposes) is still a fairly manual procedure today due to the restrictions on how vMotion works on the network and with storage networks. Not to get too much into the weeds, but these are critical issues that need to be addressed before vMotion can actually act as the backbone for things like vCloud and truly mobile workloads.

And I love your plug for securing the workload both in transit and once running in the new environment. Ideally this would be part of the vApp wrapper and carry with it credentials for spinning up and using the VM. I think this one may be the largest challenge to get past in your list.

-Alan

[bnara]

James, this is very good post and I really like your idea of a federated cloud. However, the benefits of a cloud of clouds go far beyond the structural advantages. At the application level, a cloud of clouds that connects say the Salesforce cloud to Google and Facebook has the ability to reinvent business processes by combining data that had in the past existed on separate islands. A couple of examples would be using social information during the sales or recruiting cycle and using transaction context during an email or IM interaction. This is topic I am very interested in and have written about in more detail on our blog (http://www.appirio.com/blog/2008/12/cloud-of-clouds-first-in-series-on-our.php)

[jamesurquhart]

It is true that I stayed away from the PaaS and SaaS stories here. To be honest, I'm still thinking through what is integration vs. what is mashup vs. what is true workload migration in those offerings. I will certainly check out your blog for clues... :-)

James

[alainyap_morph]

Cloud Federation is exciting! Does remind me of "May we live well and prosper!"

Happy Holidays, James!

Best.
Alain

[disambiguated]

Good stuff, James - however, it's important to note that workload mobility <> VM mobility. Workload mobility is a layer-7 function which has to do with application logic and data domiciling.

Also, we mustn't forget about transactional and/or data dispersion - i.e., cloud models in which both applications and data are distributed in nature. I believe this will become the norm. In fact, it's already being done crudely with existing transactional models such as booking sales in a particular geography in order to gain tax advantage; the other factors you mention will come into play, as well, along with capacity and market pricing, all negotiated dynamically and constantly re-optimized.

[jamesurquhart]

There is theory and there is reality. Today, that layer-7 function is "packaged" in a VM. I would agree, however, that middleware vendors such as Gigaspaces are demonstrating application mobility at a higher level of the software stack.

James