So once we have the intercloud, what are we going to do with it?

Some debate is heating up, at least on Twitter, about a variety of cloud-related topics. As James Urquhart pointed out in his “Three debates that will benefit cloud computing” debate is good, because it fuels innovation and drives markets forward.

One of the things that’s frustrating about new technology and concepts is that terminology often confuses the discussion. We periodically still see discussions – and debates – around the definition of cloud computing, after all, so that shouldn’t be surprising at all. Intercloud is another one of those terms that is going to cause some contention because it sounds like a technology, but apparently it’s not. According to the folks who started using it (like James) it’s more akin to the Internet in that it’s a description of what will grow out of interoperability and portability standards once they’re applied to actual implementations. Not to get all Euclidian, but the intercloud is a lot like the set of all clouds connected via standards-based mechanisms. What those mechanisms are may be up for discussion and there are certainly groups devoted to defining those mechanisms but suffice to say that right now the “intercloud” does not exist. It (probably) will but we’re a ways off from that.

But because the intercloud is more of a set of capabilities it really doesn’t do anything. Intercloud is like the Internet is like the network – without someone or something (usually applications) leveraging it, it’s just, well, there. So what could we do with intercloud besides avoiding vendor lock-in?

There are a couple of things that spring to mind; specifically cloud balancing and its closely related cousin, cloud bursting. I say closely related because, despite protests to the contrary, they are based on the same technological concepts and architecture, and work best when leveraging the intercloud. 

Cloud bursting has already been talked to death but just as a refresher cloud bursting is the practice of “bursting” into a cloud when capacity has been reached in the corporate cloud/data center. The business case for cloud bursting primarily revolves around seasonal or event-based peaks of traffic that push infrastructure over its capacity but are not consistent enough to justify the cost of investing in additional hardware that would otherwise sit idle.

Cloud bursting takes advantage of global application delivery (load balancing) – or some strategic control point that acts very much the same - as a means to provide nearly immediate redirection of requests to an external cloud in the event that corporate resources are depleted. When a request is received the global load balancer decides which data center (corporate or cloud) should handle the request based on its understanding of capacity. Other variables can of course, be introduced, but basing the decision on where to route a request on other business or technical metrics immediately moves the architecture into one of cloud balancing, not cloud bursting.

So basically there’s a rule that tells the global application delivery solution to direct requests to CLOUD A or CLOUD B when the CORPORATE CLOUD is near or at capacity. It’s a bit more complex than that in implementation, of course, but when distilled down to its basic operations, it really is that simple.

Cloud balancing is the routing application requests across applications or workloads that reside in multiple clouds. It assumes that all instances of the application deployed in the various clouds are accessible at all times, which makes it different than cloud bursting as bursting may actually require the deployment and/or launching of the application at a remote cloud. Cloud balancing is not simply load balancing across clouds. The simplification of load balancing down to a dumb process is part of what causes problems with the definition of such concepts. If one assumes that load balancing in general is a rudimentary, dumb process that has no awareness of context and no ability to make intelligent routing decisions then I suppose that the misconception that cloud balancing and cloud bursting have very little in common makes more sense.

But load balancing has not been, for quite some time, dumb. It evolved years ago into what analysts and vendors call “application delivery” and it is capable of quite intelligent, on-demand request routing based on everything from technical to business metrics. Cloud balancing requires that level of intelligence; it requires a context-aware decision maker that can collaborate with the rest of the infrastructure and solutions providing business-level metrics and information in order to make a decision, in real-time, regarding which “cloud” should respond to any given request. Service-level agreements, business metrics, response time, capacity, cost, power, etc... Any one or combination of these variables can provide the basis for deciding how to route a request.

So basically there’s a set of rules that tell the global application delivery solution to direct requests to CLOUD A or CLOUD B or the CORPORATE CLOUD when certain conditions exist. Those conditions are contextual, which is why the notion of context-awareness in application delivery solutions in general is an imperative when architecting a cloud-based (on-demand) infrastructure.

Both cloud balancing and cloud bursting require intercloud in order to be as seamless as they are intended to be because without the interoperability and portability across clouds, well, things start to break down. Sure, you could do it without standards, i.e. today, but the cost and effort to do so is probably not going to engender a lot of tinkering in this area. The standards need to exist so the actually development and deployment of applications across multiple clouds is not only technically but financially feasible. Standards need to exist not just for deployment, but for management and gathering of data – the data that will be needed in order to utilize clouds based on business and operational metrics. Those operational metrics can – and should – include more than physical conditions on the network and in the data center, but also those describing costs – down to the cost of power at the moment, if possible. Business metrics should include cost thresholds, SLAs, and KPIs specific to the business. All this data is part of what makes up context, and context is what makes things like cloud balancing and cloud bursting valuable architectures. 

Context-awareness is the foundation of a dynamic infrastructure and a dynamic infrastructure requires integration and collaboration in the network and application network infrastructure, hence the focus on standards and interoperability. Only when a solution is capable of interpreting the myriad variables available from layer 2 through layer 7 (and beyond) can it start making decisions that are based on real-time conditions and business parameters rather than just CPU or memory resources or connections or response time. Certainly these are valuable factors in the overall equation, but the goal of IT and solutions implemented and deployed by IT is to provide business value. It stands to reason, then, that business goals and parameters and metrics should be a part of that implementation.

Cloud balancing isn’t as simple as it sounds, simply distributing requests in an orderly fashion across X number of clouds. It is, like modern load balancing in general, an intelligent, policy-driven, interpretive method of routing application requests in a way that adds significant value to the organization. From a process standpoint cloud bursting and cloud balancing are the same thing. Both leverage global application delivery as the real-time decision maker regarding how requests are to be distributed.  One might even go so far as to say that cloud bursting is a subset of cloud balancing as the former is more restrictive about when external cloud resources may be invoked than is the latter. But really, the big differences between the two are the metrics and business use-case in which they are utilized. That’s where the real value of these new-fangled ideas comes from: it affords IT agility which fuels business agility. It isn’t just about the bottom line or speeds and feeds, though these are certainly part of the equation. It’s about providing a framework through which the business and IT can innovate new ways of leveraging technology, and that enables other technology related markets to develop and deliver innovative solutions that provide value to IT and the organizations it supports.

Related blogs & articles:

• Governance: Service Catalogs and the Cloud
• Intercloud: The Evolution of Global Application Delivery
• Getting Around That Pesky Speed of Light Limitation
• The Infrastructure 2.0 Trifecta
• F5 and the Cloud
• OVF: A few layers short of a full stack
• The Context-Aware Cloud