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.
Dear all, I'm having a trouble with ACI when receiving TCN BPDU. I have 2 VPC that is connecting ACI leafs to 2 VSS switch (using 2VPC). I understand that whenever I migrate servers from legacy switch to ACI leaf, legacy switch will generate TCN and ...
Good Day I have 4 MDS 9148 Fiber Channel Switches I want to re-use for a development network. They are older of course, But we just need a system where I can connect a VNX 5500 to a few Servers. I have searched the internet and I have found the "proc...
ACI PathTenants > Networking > External Routed Networks >In the area with the routing protocol check boxes, there are a few options such as BGP, OSPF, and EIGRP.In this image, BGP and OSPF have been enabled.What is the equivalent CLI command for ...