What Is NOT Networking for the Cloud
Recently I read a post about networking for the cloud, even listing a trademark on an associated term. I certainly am no IP lawyer, but it strikes me as not the most judicious use of time and funds to trademark Cloud X and Cloud Y and Cloud Z as they relate to whatever a company is doing. Shameless ‘hopping on the bandwagon’ if you ask me… but again, we have enough IP bloggers around here, so am not going to pursue that path too much, but instead let’s cut through some of the hype and ask a pretty serious question…
‘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.
1) It is not about just low latency. Certainly a reasonably low, and deterministic latency on packet transport allows applications to process more rapidly. This of course depends on the application, how distributed it is, what gets processed where, and a host of other factors that happen far above the Network and Datalink layers, but assuming most things are equal - lower latency means apps process faster. There is a caveat there though that needs to be explored a bit. Low latency is great, but deterministic latency, or consistent latency is equally as important. Also how the device performs with differing IP traffic types (think unicast vs multicast and jumbo frames and erroneous packet types is another consideration).
And the most important point, about Cloud Computing is that it is in the cloud. and the cloud is the Internet. The Internet has some of the longest latencies, and by its very nature the most variability in latency (except maybe satellite transmissions). So how you buffer and flow control to address variable latency is important, and I would affirm in the cloud space more important than counting nanoseconds.
2) It’s not all big pipes. I know, I wish the world were all 10Gb Ethernet too. I also wish I had 100Gb here today so we didn’t have to focus so much on elegant link-bundling technologies. (this is a major area of network improvement in general in my opinion by the way, and may be worth another blog post on how to improve these…) Video is neat - it drives 5-10Mb/s, 15Mb/s for a big Telepresence. But moving a virtual-machine from one place to another may move up to 40GB of data, or 320Gb. This would mean that in the course of an hour each VM movement is equal to about six concurrent TelePresence sessions in network demand. Compound this with VM sprawl, Dynamic Resource Scheduling, and data center consolidation and yes, there will be a heck of a lot of data moving between servers, between data centers, and with cloud computing from enterprises to service providers.
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.
3) It’s all about the end point, the network is just dumb plumbing. Ok, as much as I hate to admit it being a Cisco employee now for over a decade I will begrudgingly admit it is possible to build a network that forwards packets to the correct destination end-point without using all those multi-letter acronyms we like to put at network problems. It is also possible to build enough intelligence into your application that it can work around the deficiencies of these sub-standard implementations. But in IT, or in any business or engineering challenge it is imperative to do a couple things:
a) Use the right tool for the job
b) Execute ongoing jobs in the most efficient way possible.
While it is possible to build the sub-standard network described above, it is not optimal to do so. It is not the most efficient way to execute IT workloads. An infrastructure for IT, just like an infrastructure for a bridge has to be balanced. It has to balance stability with cost, security with access, scale with performance, etc. Over correcting on one vector negatively impacts the entire infrastructure. The right architecture is not a server centric, application centric, or network centric architecture. It is an IT-Centric architecture that brings into balance the capabilities and requirements of the business, doing the right job, in the right place.
Addressing portability is a classic network problem, and if customers demand interoperability between their systems and their providers or even potentially between providers then there are and will continue to be network problems to be solved, open standards to be developed to codify the solutions to these problems, and infrastructure that scalably runs these open-standards.
So, in conclusion, some companies will build products, brand them for the ‘cloud’, trademark what you will, but hopefully, in the end, realize that what the cloud computing market will need are systems that are purpose-built to provide the right types of performance, security, scale, management, and addressing and policy portability for IT workloads. Not just marginal differentiation.
dg
Posted by Douglas Gourlay at 12:40PM PST
Mitch Moore Jan 8, 2009
I realize that within any Blog there is an element futuristic visionary commentary. I, like the author, am continually annoyed with the hurry up and define it so we can build it mentality without actual user requirements and benefits.
Cloud computing is often referred to the next step in the grid computing process. This is little more than a metaphor for grid computing with subsequent revenue.
Latency, bandwidth, or processing power are only a few of the factors in the quality of experience that a user seeks. The truth is that we’ve been down the thin client road. We’ve been down the paid cycles at the supercomputer road. Until we get to what Cloud computing does (not can do, not should do, not might do) which is better than what is available now, making blanket statements about what will effect it’s capability / functionality is a sincere waste of time.
Going a step further and running out to claim name ownership is no better than internet name squatting. To whoever did this, I hope your mommies and girl scout troops are proud.
Mitch