« Accounting for Cloud Fans - Clouding for Accountants & CFOs | Main | VMware ESX Health Check Tools »

Networking for the Cloud - Musings to Myself (and Doug... and Greg...)

Doug Gourlay does a nice job taking the air out of a few of folks regarding networking and "the cloud."  He makes the case that

  1. It's not just about low latency...

  2. It's not all about big pipes, and ...

  3. It's not just about the end-point(s), with the network being just a lot of dumb, rather static inter-tubes.

I'd have to agree for the most part.  (There are always specific instances -- like companies that are considering cloudbursting -- where latency or throughput will make a big difference.  Doug's not dismissing these issues as irrelevant.  But, he is saying that these are not sufficient as THE list of considerations.)

So, what IS networking for the cloud about?

Greg Ness and others in the Dynamic Infrastructure / Infrastructure 2.0 posse (which includes Cisco) would agree that it's no longer "speeds and feeds."    Greg in particular makes a case for automation as being at the core of the "network evolution." 

The problem I'm having is understanding exactly what is meant now by "network automation."  What I would personally be unable to stomach is a return of a reliance on concepts like "autonomic networks" or "self-healing networks."   We're in need of something more systemic and all-encompassing... networks that are "application responsive" or "application platform aware."  (I recall the initial description of SAP's Adaptive Computing, and think it's possibly closest to that idea. The realities of managing virtualized landscapes in response to application platform demands has reduced my expectations for AC, but I certainly liked the concepts.)

OK. So, we have now incorporated application responsiveness to our list.  But, I'm still not satisfied that we know what comprises the necessary and sufficient components of Dynamic Infrastructure.  It's not enough to "automate" or "routinize" what have been manual processes, even if they are triggered by the demands of an application.  The results of these efforts always promise too much and end up delivering expensive, brittle and (frankly) overly constrained results.  Nope.  There's got to be a capacity to adapt -- to bounce back or return to a preferred state.   That sounds to me like a form of resilience -- returning to the "right shape".  Perhaps what I'm looking for is a comfortable (comforting ?) definition of resiliency for Infrastructure 2.0.

If we go back to first principles in computer networking, we can always find an "official" definition:

Resilience is the ability to provide and maintain an acceptable level of service in the face of faults and challenges to normal operation. 

Not very satisfying, is it? For a number of us old guys who grew up with the initial networks, the concept got turned inside out and became "the absence of single points of failure", and then the ability to dynamically route around failed/failing equipment.  That won't do.  There are (at least) two ways in which the old approach fails and will require improvement.

Bouncing back.  When talking physical materials, engineers describe the ability of an object to return to its original shape as "resilience."  When talking about Dynamic Infrastructure, it seems important to state at the outset that the fluid, dynamic nature of the demands on the datacenter means that we do not always want the infrastructure to return (or try to return) to exactly the same configuration that took the hit.  What we want is an infrastructure, composed of material (dare I say fabric ?) that, in response to demand, maintains the levels of service by returning to an improved configuration or an alternative shape that can better withstand and better respond to the demands.

Anticipation.  The problem with automated resilience as we've seen it implemented in the past is that it's almost completely reactive.  It waits for a fault, or the degradation that presages an impending fault, and then takes remedial action.  We know in advance that the Dynamic Infrastructure has to deal with the migration of virtual machines and n-tier applications that have their component parts suddenly "appear" at almost any location in the physical plant. What can be incorporated into the Dynamic Infrastructure that takes this into account, so as to "bounce forward"? 

I'm not sure where this is leading.  What I DO know is that I'm not willing to let the Cloud Posse talk about automation without getting down and dirty about fundamental aspects like resilience and anticipation.

What Is NOT Networking for the Cloud - Data Center Networks

‘What does Cloud Computing demand of a network?’—Some have asserted that, ‘it’s all about low latency’. Others ‘its all about big pipes’. And yet another group states, ‘it is all about the end point, the network is just plumbing.’

I respectfully disagree.

Reader Comments

There are no comments for this journal entry. To create a new comment, use the form below.

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
All HTML will be escaped. Hyperlinks will be created for URLs automatically.