Welcome!

@CloudExpo Authors: Zakia Bouachraoui, Elizabeth White, Liz McMillan, Pat Romanski, Roger Strukhoff

Related Topics: @CloudExpo, Open Source Cloud

@CloudExpo: Blog Feed Post

Cloud Balancing, Cloud Bursting, and Intercloud

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

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. 

distributedclouds


CLOUD BURSTING


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


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. context

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.


IT’S ALL ABOUT CONTEXT and AGILITY


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.

 

Follow me on Twitter View Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share

Related blogs & articles:


Categories:

Read the original blog entry...

More Stories By Lori MacVittie

Lori MacVittie is responsible for education and evangelism of application services available across F5’s entire product suite. Her role includes authorship of technical materials and participation in a number of community-based forums and industry standards organizations, among other efforts. MacVittie has extensive programming experience as an application architect, as well as network and systems development and administration expertise. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she conducted product research and evaluation focused on integration with application and network architectures, and authored articles on a variety of topics aimed at IT professionals. Her most recent area of focus included SOA-related products and architectures. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University.

CloudEXPO Stories
The precious oil is extracted from the seeds of prickly pear cactus plant. After taking out the seeds from the fruits, they are adequately dried and then cold pressed to obtain the oil. Indeed, the prickly seed oil is quite expensive. Well, that is understandable when you consider the fact that the seeds are really tiny and each seed contain only about 5% of oil in it at most, plus the seeds are usually handpicked from the fruits. This means it will take tons of these seeds to produce just one bottle of the oil for commercial purpose. But from its medical properties to its culinary importance, skin lightening, moisturizing, and protection abilities, down to its extraordinary hair care properties, prickly seed oil has got lots of excellent rewards for anyone who pays the price.
The platform combines the strengths of Singtel's extensive, intelligent network capabilities with Microsoft's cloud expertise to create a unique solution that sets new standards for IoT applications," said Mr Diomedes Kastanis, Head of IoT at Singtel. "Our solution provides speed, transparency and flexibility, paving the way for a more pervasive use of IoT to accelerate enterprises' digitalisation efforts. AI-powered intelligent connectivity over Microsoft Azure will be the fastest connected path for IoT innovators to scale globally, and the smartest path to cross-device synergy in an instrumented, connected world.
There are many examples of disruption in consumer space – Uber disrupting the cab industry, Airbnb disrupting the hospitality industry and so on; but have you wondered who is disrupting support and operations? AISERA helps make businesses and customers successful by offering consumer-like user experience for support and operations. We have built the world’s first AI-driven IT / HR / Cloud / Customer Support and Operations solution.
ScaleMP is presenting at CloudEXPO 2019, held June 24-26 in Santa Clara, and we’d love to see you there. At the conference, we’ll demonstrate how ScaleMP is solving one of the most vexing challenges for cloud — memory cost and limit of scale — and how our innovative vSMP MemoryONE solution provides affordable larger server memory for the private and public cloud. Please visit us at Booth No. 519 to connect with our experts and learn more about vSMP MemoryONE and how it is already serving some of the world’s largest data centers. Click here to schedule a meeting with our experts and executives.
Darktrace is the world's leading AI company for cyber security. Created by mathematicians from the University of Cambridge, Darktrace's Enterprise Immune System is the first non-consumer application of machine learning to work at scale, across all network types, from physical, virtualized, and cloud, through to IoT and industrial control systems. Installed as a self-configuring cyber defense platform, Darktrace continuously learns what is ‘normal' for all devices and users, updating its understanding as the environment changes.