Kicking of the new year (and a new decade) with a lively debate on a technological concept that is barely out of its infancy is always a good thing. Fred Cummins over at HP recently penned “Pursuit of the Intercloud is Premature” and caught the eye of several of us for whom Intercloud is near and dear and, I think, provided a great way to start off the year by declaring the concept of Intercloud “not yet worthy of concern”. 

If this elastic mesh is provided by a single cloud provider, then it is simply a different spin on cloud computing.  If it is a mesh of independent cloud providers, sharing workloads, then it is a vision that is not worth concern within the next decade. [emphasis added]

I’m going to have to disagree with Fred for two reasons. The first is based on the rate of change and innovation in technology in the last decade that certainly points to the next decade being just as disruptive. Consider that ten years ago, in the year 2000, most of the web as it exists today – Web 2.0, APIs, integration, collaboration, video, audio, user-generated content – didn’t exist. From a technology perspective virtualization wasn’t even a twinkle in a VC’s eye and in the infrastructure world, well, we were just beginning to explore the advantages of moving software-based solutions to hardware and hadn’t fully managed to integrate infrastructure solutions let alone anything else.

The rate of change in technology makes a “decade” in real time more like a century in technology-time, as far as innovation and use of new technology goes. So to say that the vision of Intercloud isn’t worth concern for the next decade isn’t realistic. It is imminently more practical to consider where we want to be in ten years and head in that direction than it is to stand pat and let our options essentially stagnate.

The second reason I’m going to disagree with Fred is on the basis that Intercloud is not an “exclusive or” concept. We are not “here” or “there”, but rather we’re going to be, for some time, “somewhere in between.” Intercloud is an evolution from where we are now to where we (think we) want to be – a customer defined mesh of independent cloud providers sharing workloads. As we move through this next decade we’re going to see the application of Intercloud concepts being applied in an evolutionary – not revolutionary – manner.

Intercloud today in a simple, amoebic form exists as simply the inclusion of cloud computing hosted workloads in a global application delivery strategy. Where we once leveraged multiple data centers and global server load balancing (GSLB) to improve application performance and availability we will – and already are in many cases – leverage cloud computing environments in much the same way. This is not futurama, it’s fact. The use of GSLB and layer 7 (application layer) content-based routing to distribute workloads across individual servers (physical or virtual) is hardly much different than using those same technologies to distribute workloads across data centers – whether those data centers be physically owned by the organization or rented by the hour from a cloud computing provider. Leveraging cloud-based storage for images or other static content and the subsequent integration with on-premise applications is very similar in implementation to the use of CDN (Content Delivery Networks) and thus not a stretch to imagine that organizations will take advantage of cheaper storage options available “in the cloud” for their image-heavy applications.

The next step is to incorporate business-layer metrics into the decision making process when workloads are distributed across data center implementations, cloud-based or otherwise. When the global application delivery platform is able to base its decisions on where to route a given user and request on business-layer metrics such as costs and location as well as on performance and availability metrics, then we’ve moved beyond simple GSLB and into the realm of cloud balancing. Cloudbursting and cloud balancing are simply evolutionary steps in Intercloud, transitioning us from static application delivery architectures to more fluid, dynamic architectures that take into consideration the context in which requests are made and base service-related decisions on all the variables available.

Evolving from that will be the ability to actually move workloads on-demand based on those same variables. Today it is assumed that the workloads and/or resources already exist in several locations. Indeed, without existing application instances cloud bursting and cloud balancing are not really efficiently executed today. Though there are ways to migrate workloads on-demand today, it isn’t universal and requires very specific conditions. Experience and, one hopes, standards will smooth this process until it’s ubiquitous and seamless. But as we continue to refine the migration in real-time of virtual images and application packages across data centers (including cloud computing providers) we will eventually get to the point where that vision of “an elastic mesh of on demand processing power deployed across multiple data centers” is not just a vision, but a reality.

That said, Fred makes some very valid points and raises questions/challenges that certainly must not be ignored:

The economies of cloud computing come from optimization of operations supporting a homogeneous computing infrastructure that is driven by market demand and a high degree of trust in the cloud service provider.  Cloud providers must make choices of technologies and develop optimal operations based on a high level of automation.  They must commit to levels of service, security and reliability.  They must make services easy to use and responsive to problems.  This is a rapidly evolving market.  Different providers will make different choices, potentially appealing to different markets.  They cannot optimize if they must also maintain compatibility with other providers.  In addition, they would need agreements for ensuring quality of service and establishing cross-billing mechanisms.  Computing and storage resources are not free like the Internet.  A client is not going to turn over data and applications to be managed somewhere in a network of independent providers.  Who would be held accountable for failure to perform or breaches of security?

I don’t think anyone is suggesting that Intercloud become a free-for all, where data and applications are willy-nilly moved around without the owner’s consent or knowledge. That kind of a situation would certainly, as described by Fred, be potentially disastrous. What the standards around Intercloud will hopefully do is exactly what Fred exhorts such standards do: “avoid service-provider lock-in” and enable “integration between business applications and services using Internet protocols.” Such standards should also "make services easy to use” and provide the ability for customers to determine where and when application workloads should be moved. That is, and always should be, a customer-driven choice, not a provider-driven choice, and Intercloud standards must allow for customer control over workload execution with as much granularity as possible.

It appears, too, that some of Fred’s arguments are based on the premise that applications residing in “the cloud” or in multiple “the clouds” are also being managed and controlled in “the cloud”. That’s not necessarily going to be the case – though it’s certainly a possibility. If we extend current global application delivery models to take advantage of cloud computing environments the control and management is still on-premise, or at least it can be. Cross-billing isn’t an issue, then, because the contracts are between provider and customer, not provider and provider. Each provider is responsible for breaches in security in only their environment, just as hosting providers today are only responsible for their environment if though a customer might be leveraging multiple hosting providers. For specialized services such as a cloud computing provider partnering with another provider for DNS management, we have well-established policies that already govern responsibility and accountability and as long as the customer is aware – up front – of that partnership it shouldn’t be any more of a problem than it is today.

The mere existence of Intercloud-focused standards (or the existence of a working group to define those standards, more accurately) does not negate these goals nor is it inconsistent with Fred’s view of on what we should be focusing our energy. Many of the concerns and needs that Fred points out are milestones along the path to Intercloud, concerns that must be addressed and needs that must be met in order to reach the penultimate apex of Intercloud. (I say penultimate because there’s always something beyond what we’re striving for; some goal or technology that evolves out of our efforts to reach our current goal and thus becomes the next penultimate goal…etcetera, etcetera, ad nauseum). In fact, one of the benefits of Infrastructure 2.0 and the leveraging of dynamic control planes via standards is to ensure that providers don’t need to worry about compatibility with other providers while ensuring that customers can move between providers with ease and without loss of infrastructure functionality.

Intercloud isn’t going to be – nor can it be – a dramatic leap from one application deployment methodology to another. It’s going to be a gradual introduction of technology-related capabilities in the area of global application delivery that allow more control and freedom over the deployment and subsequent execution of workloads across data centers. It’s going to be an evolutionary process, not a revolutionary one, that is driven by experimentation and customer-demand as they leverage the capabilities of increasingly context-aware infrastructure to distribute and leverage resources.

Related blogs & articles:

• Pursuit of the Intercloud is Premature
• The Intercloud makes Networks sexy again
• The Inter-Cloud and internet analogies
• Migrate a live application across clouds with no downtime? Sure, no problem.
• Cloud Balancing, Cloud Bursting, and Intercloud
• Intercloud: The Evolution of Global Application Delivery
• Business-Layer Load Balancing
• Infrastructure 2.0 Is the Beginning of the Story, Not the End