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

22 Comments.

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

Doug,Excellent post, and I couldn't agree with you more on how we need to look at and treat the cloud based on how we're going to use it. And the infrastructure is critical to how we're going to be using the cloud - to access apps and data. Your VM over the internet example nailed it. As we get closer to seeing things like vCloud in action, I think many of the issues you raise are going to shoot way up to the top of the priority list, specifically how does the context (network, location, user, security) of the application access and delivery change as it bounces around the cloud. Those follow the app"" standards (if we're that lucky) will be interesting to follow. Nice post. :)-Alan"

Thanks Alan, appreciate the feedback. It was interesting noodling on the math the other day. Many people are astounded at the amount of data transmitted to support video, but that may be dwarfed by the movement of VMs. Will be interesting to watch.

Awesome post Doug. To your third point, I've often seen discussions of cloud security, SLA enablement, etc. become an either-or"" between infrastructure and end-point approaches.Nice explanation of how it's a combination of the two that provides an optimal solution (i.e. one that meets rqmts at scale)."

I can't imagine who that could be either! Happy New Year to you all!I seem to recall Clouds"" as part of DC 3.0 in December 2008 from the author.Whatever the term or spin, internet, cloud...Its all about networking models for computing ; A Balanced Network of performance (latency, scale, guaranteed packet delivery), resilence and open Extensibility. Will post more white papers for you to read and blog some more.....including real customers......"

I received some offline feedback from several concerned parties who state that, in summary, this is a confusing post because I:1) mix latency 'within the cloud' with latency 'across the internet'and2) acknowledge the need for bandwidth within a cloud for moving workload, but then say that since you cannot get that between clouds there is no solution. and 3) Roland's comment on VM migration- I focus a bit too much on the VM rather than the end-state of 'true cloud computing'.Let me explain. 1) Let's assume one switch is 200ns faster than the next switch. In some situations this may actually matter. But once the end-result of this processing has to cross over the Internet- with variable latencies measured in milliseconds, four orders of magnitude different than the latencies of the single switch in the data center, the net-gain is marginal if any. I simply argue that more focus needs to be placed on ensuring the connections between the enterprise and the capacity-provider than nanosecond-shaving when a) it doesn't matter as much in a cloud because of the remote and mobile nature of where the workload can be processed, and b) it is a metric with increasingly diminishing returns constrained in the end by the speed of electrons flying through wires. (we can't beat that whole speed of light thing yet...)2) And as far as the bandwidth- I acknowledge that big pipes are nice, I wish the whole world was comprised of 10GbE to the server with 100Gb capacity in the core. But just throwing bigger pipes at the problem without ensuring that the capacity is capable of being intelligently utilized, while maintaining all the features necessary to establish and maintain trust, addressing, reachability, scale, and security while the workloads are mobile is the bigger problem. Oversimplifying to 'big pipes = cloud ready' is a mistake, and is a rather myopic viewpoint.3) I do not feel the current concerns about VM Migration are 'transitional' unless we look in time horizons of decades. The mainframe architectures in use 20 years ago are still used today. The OS architectures of the 1980's are in use today. The Web programming models of the 1990's are in use today. If 'true cloud computing' is the dissolution of the OS and the integrated abstraction of the hardware from the workload I think it is a multi-decade journey and not one I would predicate current IT architectural decisions or current IT product developments on seeing in the next several product cycles. The VM is a logical unit of abstraction between HW and SW/OS. It moves. With some of the newer management tools coming out they move more often. They absorb existing x86 workloads, in many cases without recoding. So for the rest of this decade and I would imagine most of the next, I think we will still be burdened with some of today's architectures, and have to design systems to optimize them.With Data Center 3.0 do we talk about 'Cloud Computing'? Absolutely. We see Cloud computing as the next generation of Data Center architectures, where workload is portable between enterprises and providers, dynamically, statefully, and most importantly in a trusted manner. We see that the providers need to evolve to offering Enterprise-class cloud computing services based on ensuring SLAs, Security, and Interoperability. Do we talk about Cloud Computing, linking cloud computing franchises together, and building markets for cloud computing services? In a word, Yes. This is networking for the cloud.

On the contrary Jayshree I think this is one of the best Cisco posts I have seen, for several primary reasons.- Cisco has a holistic offer in the datacentre, not a point product. It takes a few terms to describe that broad of an offer, some of which you list.- Blogs are designed to create controversy. This is the first time I have ever seen an opposing CEO commenting on a public blog of their former employer. Amazing Cisco let it get posted. - Doug makes many very valid points that it is not just about bandwidth, latency, or the end-points. It is about the system and architecture.- Lastly, Dell lost their TM for 'Cloud Computing' because it is a generic term and a shameless land-grab. Why build your entire marketing framework around a similarly poorly conceived/executed attempt at trademark skygrabs? http://tess2.uspto.gov/bin/showfield?f=doc&state=jf8vnn.6.1http://www.bmighty.com/blog/main/archives/2008/08/dells_cloud_com.htmlhttp://www.bmighty.com/blog/main/archives/2008/08/dell_loses_bid.html

1.Yes, I would say not one of your better blogs Doug. But, I do appreciate your spirit and thank you for clarifying the contradictions and also validating Networking for the Cloud"" 2. No matter what the term, ""Networking for the Cloud"" or Arista's ""Cloud Networking"" - the inescapable architectural shift in the Data Center,should not be confused with the larger Internet or even Virtualization and Security.3. Cloud Computing requires a holistic look at network performance. Our customers and Cloud network architects don't design to one singular metric for cloud containerization. Its a balanced cloud for predictable/low latency (in nano secs to few microseconds), non blocking 1 or 10GE throughput, guaranteed packet delivery/buffers and appropriate uplinks. Not to mention the need for resilience and open extensibility. 4. By placing every possible buzz word in the DC 3.0 bucket (Unified Fabric, Virtualization, Cloud, Security, list goes on ) , you have highlighted the complexity of DC 3.0 as opposed the simplicity, price/performance and beauty of clouds in a data center. Botom line, Some thoughtful Cloud Network designs are needed to parse your words and mine . "

Hello all, from an account manager's perspective, this is all very interesting and I am very encourage to see that we are leading lights in the definition of what the Cloud actually is. As an ex-IBM/Sun person, they would contend that ths Cloud has been around for a long time (it was just called something different) and I would have to agree. The shift to being much more dependant on the network is the real change and it is Cisco that is driving this. Anyway, my comments on this (I always bring this up when Cloud is being discussed) orient around the value. The infrastructure is the enabler whilst it is the applications that will drive the adoption. Do we understand/link in to what Oracle/SAP etc etc are looking to do (remembering Larry E's last acerbic comments on this). What applications do we see the ones that will be Cloud-based first?My customer (large SP) is driving the Mission Critical non-Core"" space."

I understand your reasoning, Doug - but the future is here already. Hadoop-type systems, 3Tera AppLogic, the EC2 APIs, et.al. are the direction that we see large-scale, distributed computing taking. The only significance VMs have today for the application architects and coders - i.e., the folks who design and build these applications - is that right now, the legacy stacks they're using are based upon 'servers', and with virtualization technology, the servers are now running in VMs, instead of on discete boxes. This is not the model for current and future application development.Moving VMs around routinely as a way to balance workload is grossly inefficient and crude, because with current legacy stacks, the application logic and housekeeping does not permeate down into the OS; it's disintermediated in that regard. Relying on externalized triggers based upon OS- and VM-level instrumentation, with no tie-in to the applications, is both crude and dangerous. As application control-planes are extended horizontally, the current need to do this with legacy stacks will go away (and in fact does not exist in systems like Hadoop, EC2, and AppLogic; in particular, VMs in EC2 and similar IaaS offerings are more an artifact of the state of the technology when they were first stood up and of their billing models than anything. This will change in the medium-term future as de facto and de jure API/data interchange standards emerge, IMHO).

They will change or die. The Oracle licensing model is quite complex and allows them to charge for various server sizes/configurations and so on, and of course they're reluctant to part with that differentiation in their revenue stream.That being said, Hadoop-type systems, sharding with MySQL, etc. are becoming the norm. Oracle will either step up to the plate and ensure the ubiquity of their applications in cloud systems, or they'll end up irrelevant.Given that Oracle are very smart, I'm quite sure that they'll successfully adapt, just as they adapted from the mainframe to the distributed model. In many ways, moving into the cloud is going back to their mainframe roots.

This is indeed an interested read. With the advent of virtualization and the emergence of innovative new ways to more efficiently use and quickly re-allocate highly available resources between geographically remote locations. The movement of marketing and or branding of these network designs or resource optimizations are creating more fog than clouds with silver linings.Many of these ideas have been around for a long time for customers who have built grid networks and implemented utility resource models. Even the (TOR) Top-of-Rack switch implementation now being turned into a unit of measure to add/remove from a grid with ease creating a within rack"" economy now has itÃƒÆ’Ã†â€™Ãƒâ€šÃ‚Â¢ÃƒÆ’Ã‚Â¢ÃƒÂ¢Ã¢â€šÂ¬Ã…Â¡Ãƒâ€šÃ‚Â¬ÃƒÆ’Ã‚Â¢ÃƒÂ¢Ã¢â€šÂ¬Ã…Â¾Ãƒâ€šÃ‚Â¢s own branding spreading around just like cloud even though people have been doing it for sometime.These marketing tactics have presented smoke and mirrors for partial half solutions when data centers have evolved requiring much more holistically designed and optimized end-to-end solutions which now means from CPU core to CPU core. This will further become evident as more advanced transport signaling and congestion control methods emerge connecting data centers which require industry standard interoperability.The cloud trend really reminds me of the old service provider days of the late 90s. Vendors pointing fingers at each other having to disprove each other hop to hop for path level issues bringing about what carrier class network reliability was truly about. And each vendorÃƒÆ’Ã†â€™Ãƒâ€šÃ‚Â¢ÃƒÆ’Ã‚Â¢ÃƒÂ¢Ã¢â€šÂ¬Ã…Â¡Ãƒâ€šÃ‚Â¬ÃƒÆ’Ã‚Â¢ÃƒÂ¢Ã¢â€šÂ¬Ã…Â¾Ãƒâ€šÃ‚Â¢s support operations being key to deducing the problem and successfully helping customers. We can now see how many of those network equipment vendors are still supporting successfully the original cloud. Virtualization is going to truly make for an interesting new way to building highly available optimized networks. The next 5 years are going to be very exciting."

Fascinating discussion, including Jayshree Ullal's own blog. I guess this whole thing is ina whole lof of flux... Is their survey of cloud design patterns a good start at parsing your words and [hers]""? Time will tell."

Hi,I agree with Jayashree and DG. The cloud networking and intelligent fabric with processing element connected to this fabric will create the infrastructure for Vmotion, virtualization, state less computing, SaaS and SOA architectures, they all point to decouple applications from infrastructure and let applications float. It is very powerful concept and done in some way by Financial institutes.Shreyas

Hi Doug,Some perspectives from the branch side of the house, as we continue to form complementary solutions:http://blogs.cisco.com/innovation/comments/a_walk_in_the_clouds/I think we're going to have some fun with this in 2009.Best,Shashi

Trying add another perspective to the discussion:Cloud computing has a lot to do with software - to configure, manage, scale, migrate applications across servers/VMs, etc. The hardware infrastructure is not very different from what it was before. I see cloud networking to be very similar. While the table stakes of low latency, robustness and speeds/feeds are important, I think there would be value in data center switches following"" the cloud computing flow. What this means is that they are tied into server, application configuration and migration and able to adapt (either via pre-set rules or dynamically) to the ""flows"" of cloud computing.To me, cloud networking is a whole lot of software in addition to the hardware - similar to cloud computing itself... and I am sure switch vendors have already thought about this :-) Thoughts?Sridhar"

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.