Showing results for 
Search instead for 
Did you mean: 

Cloud Computing and the Big Pipes myth

Community Manager
By  Brian Gracely | Originally Published October 14, 2010 at 6:00 am PST


I suppose that I could have titled this blog post as, “The Value of the Network for Cloud Computing”,  but I wanted to focus on the viewpoints that I often hear from  end-users or application owners. They tend to look at the network as a  conduit to their information, and the bigger the pipe the better. The  “bandwidth is more important than oxygen” theory. While I can obviously  understand this viewpoint from groups that consume the network from the  perspective of bandwidth, it’s important to remember that the network is  the fundamental element that allows Cloud Computing (Public, Private or  Hybrid) to exist in the first place.

So let’s talk about some of the myths and misunderstandings around Cloud and the network…Myth #1 – The Cloud is all about software – In  theory, it’s entirely possible to build a Cloud out of commodity x86  servers and intelligent software. Mix in a few Virtual Appliances and  viola!! You have a Cloud. But in reality, that is rarely the case.  Whether it’s for performance reasons (dedicated ASICs or specialized  hardware), compatibility reasons (dealing with drivers for each new x86  platform), or control / compliance reasons (HIPPA, PCI-DSS, Departmental  isolation, etc.), system architects have yet to abandon dedicated  hardware for certain elements of their Data Center. At Cisco, we don’t  have our heads in the sand about the trend for some aspects to be  software virtualized. We embraced that over a year ago with the release  of the Nexus 1000v, which delivered Network and Security-level visibility to VM traffic and mobility through VN-Link technology. We have since followed-up with the Virtual Security Gateway and vWAAS.  In some instances, customers like the Virtual Appliance. In other  cases, they want the combination of software-based functionality, but a  hardware control point, such as the Nexus 1010v. All of these Unified Network Services provide system architects the flexibility to leverage software when  desired and hardware when needed, with a common set of operational and  troubleshooting methodologies.

Myth #2 – The Cloud is about elastic resources – This isn’t a myth, but many network vendors don’t seem to implement around this concept. I’ve written about this before,  in the context of understanding the risks of making certain  architectural decisions. My colleague Brad Hedlund has done an excellent  job of visually highlighting this concept in the context of the Cisco UCS, Cisco Nexus and intelligent QoS within the network. The point is that “elastic resources” aren’t just  about servers and storage, it’s a concept that needs to be extended  across the entire Cloud, including the network elements.

Myth #3 – The Cloud is about pooled resources – This  isn’t a myth either, but it’s another area where many people seem to  only focus on servers and storage. For many years, before “Cloud” become  fashionable, the network has been a pooled resource that delivered  services (bandwidth, security, segmentation/isolation, QoS, etc.) to  silos of applications. As the networks becomes more virtualized, more automated, servicing multiple tenants,  you’ll continue to see Cisco building out intelligence to support the  advance functionality required by Cloud. The type of network  intelligence that allows customers to deploy  Virtualization/Compute/Storage building blocks (such as Vblock and SMT).

Myth #4 – Virtualization makes the Cloud more flexible – On  one hand, this is absolutely true. Dynamically moving computing and  storage resources based on capacity and availability. Adding new  capacity in minutes through templates and clones. But this doesn’t come  without some challenges to the infrastructure. For example, a vMotion or  Live Migration or XenMotion requires that both the source and  destination be on the same logical Layer-2 domain. And if ask most  VM-Administrators, they will tell you that it’s not unusual for their  environment to have 1000′s of VM migrations in a month. So they have  this great new compute and storage flexibility, but they are bound by  old L2 / L3 boundaries. If only they could build big, flat L2 networks without the worries of constant Spanning-Tree meltdowns. Or better yet,  what if they could build networks that allowed that big, flat L2  concept to expand beyond a single location, making Application-Mobility and Disaster-Avoidance much more interesting? Just as we enhanced the network to support  voice, video and other real-time services, the network needs to evolve  and adapt to the changes the come from virtualization and dynamic  computing environments.

Myth #5 – A VM is just like a server, only in software – Not  exactly. It’s true that the application and Guest OS probably don’t  know the difference, but your Network, Security and Compliance teams  sure do. A VM doesn’t start and stop at the end of an Ethernet cable  anymore. In fact, it’s possible that its traffic may never even touch  that cable if it’s talking to another VM within the same host. Or it may  move from host to host multiple times a day, dragging gigabytes of  traffic with it (VM and Storage). Wouldn’t it make sense to have a Cloud  environment that could log that movement? Wouldn’t it make sense to be  able to allocate policy (Security, QoS, Role-Based Access, etc.) to  those VMs as they moved around, so they can’t be comprised if they move  to some place they shouldn’t be? Wouldn’t it make sense to take the  handcuffs and blindfolds off the team that helps troubleshoot problems  when clients call and complain that, “my application seems slow today!!”  I would think that most VM-Administrators would welcome that  capability, especially since they are now asked to know about VMs, Backup, Disaster Recovery, Guest OS, Storage and all the  other elements that now have hooks into the virtualization stack.

Myths #6 – Clouds are orchestrated, Networks are managed – Maybe, but this assumes that your computing environment and applications are still silo’d off from your network. We tend to look at things differently at Cisco. Not only do we believe that technologies like virtualization  are driving the need for tighter integration between computing and  networking, but we also believe that a greater level of automation and control needs to be driven across both of those domains. A level of automation  that allows self-service workflows and policy-driven capabilities that  can be accessed via open interfaces.

We could keep adding to this list, but hopefully you’re starting to  get the bigger picture. Cloud provides an incredible new set of  capabilities for end-users and applications, but to truly build Cloud at  scale requires thought around Network and Security layer functionality.  The kind of functionality that Cisco can uniquely deliver across both  software and hardware platforms. Limiting your architecture to just big  pipes only means you’ll hit the barriers for scale and availability at a  much faster pace.

Content for Community-Ad