Telematique, water and fire.

Infrastructure Services: Hard Core, Soft Core, Fluffy Core...?

I've spent a good portion of my waking/working time over the past two days at Cloud Interop and Cloud Connect in Santa Clara.  During the conversations and presentations, particularly those at Cloud Interop, I kept having a nagging feeling that a critical set of concepts was missing on the part of the group.  A lot of it had to do with my personal thought experiments about cloudcenters and Infrastructure-as-a-Service (see Geva Perry's take on the concept and some issues).  

I then ran into Hoff's post from earlier today about infrastructure and his epiphany about core services.  It's worth reading, though it's still leaving me with the nagging sensation.  I'm looking for a thought experiment (or two) that will help out with a couple of notions.  This might not be the right one, but perhaps it will help point to the issues.

• The starting point: I have created a hybrid datacenter, in which I am permitted by the powers that be to use the internal, corporate datacenter in combination with cloud-resident services to deliver the corporation's "datacenter infrastructure."

• Is there ever a scenario in which I might rely on IaaS for ALL of a core network service ... such as DHCP or some other aspect of IP address management ... even though all the consumers of the core service live inside my corporate datacenter, and none (for the moment) are operating in the cloud?

• Might I ever consider operating my entire corporate datacenter, utilizing NO externally (outsourced, offsourced) infrastructure services BUT a core network service?  Some other core infrastructure service?

• If I take as fact (and there's no reason to doubt it) the Infoblox assertion that cost of IP address management exhibits a diseconomy of scale, would a logical / rational place to seek a solution be in the purchase of realtime, core network services from a particular class of IaaS rather than purchasing a new class of core service "box" that gets installed on my premises?

I don't know enough about the operation, administration and management issues involved in answering this multipart question.  But I'm sure some of you do.  If you feel so inclined, please help me out with the answer... or tell me that I've asked the wrong question.  At the very least, take a look at Hoff's post.  Then give this a couple of cycles.

Postscript:  Although it's not a core service like the examples I use above, email spam and malware identification and disposal is a very good example of a service that I'd realistically commit-- in total -- to the "cloud" even though I'm retaining "everything else" in-house.

Are there any analogous core infrastructure services?  If there are, what makes them functionally and economically viable? Are there specific characteristics and general principles we can identify regarding the core infrastructure services that would suggest a potentially successful (i.e. cost-effective ?) cloud service core infrastructure offering?

Rational Survivability: What To Do When Your "Core" Infrastructure Services Aren't In Your "Core?"

...

The reason the light bulb went on for me is that I found that I was still caught in the old school infrastructure-as-a-box line of thought when it came to how I might provide the CDN/Caching and distributed DNS capabilities of my imaginary service.

...

Do I pick a provider that offers as part of the infrastructure a specific hardware-based load-balancing platform? Do I pick on that can accommodate the integration of a software-based virtual appliances. Should I care? With the cloud I'm not supposed to, but I find that I still, for many reasons -- good and bad -- do.

I never really thought about simply using a cloud-based service as a component in a mash-up of services that already does these things in ways that would be much cheaper, simpler, resilient and scalable than I could construct with "infrastructure 1.0" thinking. Heck, I could pick 2 or 3 of them, perhaps.

...
I think it's a huge step to recognize that it's time to get over the bias of applying so called "infrastructure 1.0" requirements to the rules of engagement in the cloud by recognizing that many of these capabilities don't exist in the enterprise, either.

Infrastructure 2.0, IaaS, cloud, cloudcenter

Workload Mobility and "The Intercloud"

James Urquhart has a thought-provoking post this week when discussing a recent post by Doug Gourlay.  Perhaps the most interesting aspect of Doug's post was his explication of what workload mobility implies when it is no longer restricted to migration within the confines of a physical datacenter: the bandwidth and traffic management requirements of workload mobility in the datacenter are in great part supplied by shared network storage. The implications of data migration, vm migration and the management required to optimally (or even sufficiently) choreograph this in "the cloud" is not yet smackin' folks in the face.  But it will.

James is absolutely on target when he relates this to the issues of data communications with which the networking community was (and continue to be) confronted.  Taking this train of thought further, I find myself asking: which of the principles by which we've constructed a functioning internet can be re-applied for workload mobility in the cloud?  And, which of these mechanisms are to be quickly and thoroughly tossed out as inappropriate?  Great for Sunday-morning rumination. 

• By drawing on the principles deployed for the internet (with a small "i") to solve the cumulo-workload problem,  it implies a mix of autonomously, (self-)managed units of workload mobility combined with "just enough" collaborative agreement (and delegation) of command and control. 
• The operation, administration and management of the scaffolding and structural underpinnings must be considered with respect to all the same considerations.  (I'll tip my hand here by referring to the ISO-OSI-TMN FCAPS taxonomy.)

The data network problem seems to have resulted in solutions described as "dumb networks, collaboratively managed on the basis of the minimum number of trust relationships."  The result for workload mobility in the cloud needs to be as resilient and as adaptive a traffic system for both workload and the data (on which it feeds and which it generates for consumption elsewhere).  I hadn't seen the term before James put it on the page, but chuckled with recognition when he dropped it at the end of his post - Intercloud... indeed.

Workload mobility and the next Internet upgrade | The Wisdom of Clouds - CNET News

More than bandwidth though, which we can make the case for, how will the data move? Does the Internet itself have enough bandwidth and traffic management to support this data movement? And how will the addressing statefully move from one autonomous system to another? How will the security policy bound to a particular object (re: VM) stay consistent and coherent as the VM moves across the network and from one network to another. This is the longer term problem much more so than just the bandwidth issue, and one that is not currently being served by the hype-machines.

His observation about the immense bandwidth required to meet an open cloud with free workload mobility is a very interesting one. The live motion you know today typically bypasses moving data by leveraging shared network storage which is attached to a given VM regardless of which host it lands on.
...

Those I speak with on a regular basis about this concept have a name for it. It's a name that may take some getting used to, but a name that clearly reflects the parallels between workload mobility and data communications; parallels between this new world and what came to be known as "the Internet".

We call it "the Intercloud".

cloud computing, internet, intercloud, workload mobility

Next Gen Infrastructure Virtualization v. Infrastructure Management

Lori MacVittie has a great post this morning which draws our attention to the distinction between virtualizing infrastructure and management of a unified (physical + virtual) infrastructure using a (dare I say it?) layer of abstraction.

Virtualization Gone Wild: Infrastructure as virtual appliances

What part of the reliability, performance, and security offered by hardware implementations of core network and application network functionality are we willing to give up?

But we need the automation, the collaboration, the integration.

Agreed. We need those capabilities. But that capability can be provided without moving stable, high performance, secure network and network application functionality to virtual environments deployed on less secure, lower performance, less reliable general purpose hardware servers. We can achieve those capabilities through abstraction that decouples the implementation from the control planes required to collaborate, integrate, and automate the network and application network infrastructure.
...
Just because it is virtually possible to shove any kind of functionality into a virtual environment does not mean it should be done. The advantages gained by doing so in the application layers of the infrastructure are likely to be offset by the disadvantages if done so in the network and application network layers of the infrastructure. Reliability, security, performance. These requirements for cloud computing could easily be wiped out by moving what is stable network and application network functionality into virtualized images.

Accounting for Cloud Fans - Clouding for Accountants & CFOs

Geva Perry has done us a favor by taking something of a purist's stand on the definition of Capitial Expenditure and Operating Expenditure as it relates to cloud computing/utilitycomputing/Xaas.  He's keeping folks honest about the use of terms and (hopefully) prevents the mistake that many are making about the "inherent benefit" of moving expense from CapEx to OpEx.

What's interesting is the heated commentary generated by the post.  The economic/accounting benefits of using someone elses plant rather than buying your own has, as is pointed out, a great deal to do with context.  Variability in usage/demand, variability in the cost of capital, and a host of other variables (technical, operational and financial) play into the viability of XaaS.  This conversation is doing a reasonably good job of collecting them in one spot.  Recommended reading.

Thinking Out Cloud: Accounting for Clouds: Stop Saying CapEx Vs. OpEx

Going back to the title of this post, my point in all of this is not that there are no economic benefits to cloud computing, but that whatever those benfits are, they have nothing -- absolutely nothing -- to do with CapEx vs. OpEx, so please don't say that anymore!

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.