Last week I heard Sun Microsystems Cloud CTO Lew Tucker predict that IT expenses would increasingly track to the cost of electricity.  “Lew’s Law” (as described to a room of thought leaders) is a brilliant theorem that weaves a microcosm of IT trends and recent reports into a single and powerful concept.

Lew’s Law is a powerful idea whose time has come, with profound and far reaching impacts, including the automation of the network.

Read more...

The Hoff busts the cloud providers for the promise of infinite elasticity.

Read more...

Infrastructure 2.0 enabled application delivery platforms have more than a few things in common with the Transformers. Like Autobots, there’s more to it than meets the eye.

If you’re familiar with the mythology of the Transformers – and perhaps even if you aren’t – you know that they key attribute of Transformers is their ability to take on “alternate modes” such as cars, trucks, and winged vehicles simply by scanning the object and then adapting their own form to match.

One of the key premises of Infrastructure 2.0 is also the ability of network and application networking solutions to adapt to their environments. While they won’t be transforming their physical manifestations into some other device they can transform their configurations based on the environment in which they are deployed. Like the Transformers ability to take on alternate modes, the ability to react in real-time is a native capability of Infrastructure 2.0 solutions and should not be overlooked by those integrating Infrastructure 2.0 into their cloud-based architectures.

While everyone seems aware of the capability of Infrastructure 2.0 to be managed and integrated with the rest of a cloud-based ecosystem via a standards-based control-plane API, there’s more to infrastructure 2.0 than meets the eye, here. That same dynamic control plane can be used at run-time to transform configuration and policies to better match customer need for balancing of performance and cost across the application infrastructure. That’s the transformative power of infrastructure 2.0, and what will certainly be core to the next generation of network management systems when trying to enforce SLAs across applications, data centers, and cloud computing environments, a.k.a. cloud balancing. 

Now I doubt that anytime in the future we’ll hear application delivery controllers describe themselves as autonomous networking organisms from <insert vendor city here> still there are enough similarities between a self-optimizing application delivery network and a Transformer to run with the analogy – and as long as I have the opportunity to legitimately include a picture of Optimus Prime in my blog, well, I’m going to take it.

In the case of application delivery the “transformation” that makes this analogy work may involve many different functionalities: security, acceleration and optimization, core load balancing. Today we’re focusing on the load balancing algorithm, specifically, as the use of load balancing in cloud computing environments in order to achieve “elastic scalability” is a requirement. Unfortunately there is very little time spent on the unique challenges associated with load balancing applications executing in environments with varied compute resource capabilities. One of the mantras of cloud computing is the use of otherwise idle resources to provide the additional compute power necessary to scale an application. What this ignores is that these idle resources may very well be of different capacities in terms of CPU and RAM available. By pooling together these “servers” of varied capacities, it creates a heterogeneous environment which in turn directly impacts the entire application delivery chain. Of particular note should be the load balancing algorithm used to distribute requests across the pool of “servers.”

The problem is that by dynamically adding a server with a different CPU and RAM configuration – whether virtual or physical – to the “pool” of resources across which the Load balancer is distributing requests it changes how effective that algorithm is which in turn impacts application performance and can, unfortunately, actually render smaller instances of servers unavailable in short order. Also a possibility is that it will overwhelm the smaller server before the larger servers, which could – depending on how you have your environment configured – lead to the launching of another small server which, of course, incurs more operating costs.

Consider you have three “super size” servers, all with the same RAM and CPU capacity. A spike in use is anticipated because of some EVENT but not so much that you need a super size server, a “regular sized” server will suffice. You provision it. The spike in use occurs and then the load balancer, which has been distributing traffic based on a round robin algorithm, overwhelms the regular sized server causing timeouts, delays, and other availability and performance related problems for visitors.

What happened? The load balancing algorithm, which was perfectly suited for a homogeneous environment, was not so well-suited to a heterogeneous environment. In fact, it was downright wrong for a heterogeneous environment. What happened is that no one took into consideration that the infrastructure, optimized for a given environment, might not be so optimized if that environment changed and did not appropriately modify the load balancing configuration.

There are a number of solutions that address this particular challenge:

Provision homogeneously
If the load balancing algorithm you are using is optimized inherently for a homogeneous environment, then never deviate from that. Ever.

Human intervention
Manually change the load balancing algorithm when new servers are added, then change it back when it’s released.

Automate
Employ the collaborative nature of a dynamic control plane to automatically recognize the addition of a server that creates a heterogeneous environment and dynamically change the load balancing algorithm to one better suited to a heterogeneous environment, then reverse the change when the environment returns to a homogeneous one.

The load balancing algorithm that might be right for one application might not be right for another, depending on the style of application, its usage patterns, the servers used to serve it, and even the time of year. And changing any of those variables can have an impact on the behavior of the application because it directly impacts the load balancer.

Unfortunately we’re not quite at the point where the load balancer can automatically determine the right load balancing algorithm for you, but there are ways to adjust – dynamically – the algorithm based on the capabilities of the servers (physical and/or virtual) being load balanced so one day it is quite possible that through the magic of Infrastructure 2.0, load balancing algorithms will be modified on-demand based on the type of servers that make up the pool of resources. Today, if you know which algorithm is best given a specific set of resources you can codify the change such that it is automated; it’s only the choice of algorithm that can’t be, today, automatically determined. You probably could develop a system that does automatically determine through trial and error and monitoring of response times and capabilities, but it would not be a trivial task.

In order for application delivery infrastructure to automatically detect and optimize load balancing algorithms itself it’s necessary to first understand the impact of the load balancing algorithm on applications and determine which one is best able to meet the service level agreements in various environments. This will become more important as public and private cloud computing environments are leveraged in new ways and introduce more heterogeneous environments. Seasonal demand might, for example, be met by leveraging different “sizes” of unused capacity across multiple servers in the data center. These “servers” would likely be of different CPU and RAM capabilities and thus would certainly be impacted by the choice of load balancing algorithm. Being able to dynamically modify the load balancing algorithm based on the capacities of application instances is an invaluable tool when attempting to maximize the efficiency of resources while minimizing associated costs. Infrastructure 2.0 enabled load balancing solutions are capable of this level of automation; what they can’t do, yet, is decide which load balancing algorithm to apply. But if you know which one to apply – because you’ve tested and you know, right? – then you can automate the change based on triggers you specify, such as the addition of a server with CPU and RAM that turns a homogeneous environment into a heterogeneous environment. And vice-versa.

Virtualization and cloud computing are definitely game changers. But they not only change the basic rules of the game, they also change the strategy with which you must approach the game. It’s like moving from checkers to chess. There are a great many more moves you can make, and you’ve got to carefully consider how this move right now will impact a move you may need to make later on. One of the most important parts of that new strategy must be to recognize that while the ability to automate provisioning and integrate with the rest of the infrastructure is certainly a key benefit of infrastructure 2.0, just as beneficial is the ability to adjust and optimize the delivery of applications in real time.

Network equipment vendors today are suspended –sometimes in disbelief, sometimes in denial- in a choice between innovation and irrelevance.  The world around them has changed dramatically from the first Interop, from the powerful supply chains that have driven time and expense out of dozens of industries to the amazing rise of ecommerce in retail and banking. 

(Thanks to Wikipedia for the image)

Read more...

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.