This post is Sponsored by – My Linked Profile
There has been a good deal of FUD spread since VMware has announced their NSX network hypervisor based on software from their $1 billion Nicira acquisition. VMware is a large corporation but, $1 billion is a lot of money to any company and a big bet on network virtualization. VMware and Cisco are sounding less and less like partners and more like full on competitors. There is no question, we are on the edge of the transformation of data center network technology. We are talking the largest of stakes for both Cisco and VMware as they fight to stay relevant in both their core technologies and are striving to expand beyond their core as their respective industries continue to mature.
For VMware, the server hypervisor is quickly becoming a commodity. Hyper-V, Xen Serer and KVM are all for the most part good enough for a broad number of use cases. VMware has looked to both storage and networking as areas of growth. Specifically, for the network VMware is not looking to add network virtualization as just another feature of their server virtualization platform. They are looking to transform networking via their NSX platform by creating an overlay on top of the existing physical network there by virtualizing the network. VMware wants to stop nothing short of disrupting the network industry in the same fashion in which they have the 86x server industry.
Cisco for its part has held on strong to its lead on the enterprise network hardware front. However, the market for network hardware is extremely mature. They have looked to diversify from their core routing and switching business partially via a relationship with VMware in the x86 server market. Cisco’s choice to enter the server market with their UCS platform has been extremely successful and created a strong partnership between them and VMware. Network hardware is still their core business and in their core business the impact of enterprises moving to cloud based platforms is being felt. The size and shape of network data is being changed by this movement. Even according to Cisco themselves the enterprise and provider markets are asking for different capabilities than traditional network hardware has provided.
This places VMware and Cisco on a collision course. VMware wants to grow its network presence via software based network virtualization resulting in the de-emphasis of the management layer provided by today’s hardware based solutions. If the physical network is just a less intelligent pipe for the virtualized network overlay this will make the physical hardware that much more a commodity than it is today. Eventually, the physical network will become just a dumb infrastructure (this will take a long time) and will open the competition for network hardware. This is all true only if software virtualization can deliver on the promise of meeting the requirements of cloud providers and large enterprises.
So, other than the very future growth of two technology giants, what’s the fuss from a technology side? Both Cisco and VMware agree that some form of SDN is needed. The network needs to become an intelligent system that is abstracted from the traditional model of networking to provide agile deployment capability, scale, multinancy and flexibility needed in Cloud based environments. The growing question has been which approach is the way to take. At the risk of over simplifying the approaches, VMware takes a software first approach with extended support via virtualization aware hardware (similar to their x86 strategy). Cisco takes a hardware first approach with software as an added component. Cisco has been aggressive in framing the argument of why the software first or as they call it software only approach doesn’t work. We’ll take their argument as a way to highlight the differences in the approach and shed light into what’s real and not.
Cisco’s argument in why software first isn’t the best solution centers around three primary areas.
- Multi-Hypervisor Support
- Management Overhead
We’ll examine each area individually starting with multi-hypervisor support.
Cisco’s claim is that NSX doesn’t support multiple hypervisors. This may be a splitting hairs type of argument. In VMware’s NSX approach the network controller or hypervisor integrates on a software layer with the target hypervisors. Today NSX (Nicira) directly supports vSphere 5.5, KVM and Xen hypervisors. If you have a Hyper-v installation you must use a gateway in order to support Hyper-V hosts. This would cause scalability issues for heavy Hyper-V installations. An interesting note is that a combination of OpenStack and KVM/Xen are normally at the center of conversations around these use cases. I haven’t heard a ton of demand for virtualized networking over Hyper-V. Cisco itself has just begun to support Hyper-V with its Nexus 1000v virtual switch. It seems to me that Microsoft isn’t at the forefront of network virtualization in general.
To Cisco’s point, their hardware first approach would allow organizations that wish to bet big on Microsoft based Cloud infrastructures the flexibility to leverage existing Microsoft software without much dependency on Microsoft making changes to their software platform. In theory, an ACI based infrastructure could create virtual network ports for VM’s running on any hypervisor supporting existing protocols such as VXLAN. A hardware first based approach also would not be as vulnerable to version changes in the hypervisor. We’ll have more on this in the Management Overhead section.
This argument starts to lose some steam when you look at the NSX solution from a partner ecosystem perspective. VMware has announced several hardware partners with the launch of NSX. There is nothing preventing these partners from offering the same VXLAN support to extend the virtual network to Hyper-V based hosts in the same manor Cisco would with ACI and managed by NSX.
It’s difficult to know if Cisco has called it correctly in this area as we don’t have enough detail around how exactly ACI will look from a hypervisor perspective. We have the theory that it would work similar to how existing hardware based networking works today. On the other side of the aisle, VMware has customers such as Paypal running both ESXi and KVM on a Nicira based virtual network today.
I’m not sure where Cisco’s argument of scale comes into play. The argument may be around the fact that SDN based solutions establish tunnels for each connection within the network overlay. I can see this being limited by the capability of the x86 controller and underlying physical network. Ivan Pepelnjak wrote a great technical piece on why this isn’t a technical issue.
This is a great opportunity to highlight Cisco’s continued advancements or at least desire to continue the advancement of using hardware ASIC. The software vs. hardware ASIC argument has raged for years. The basic premise has been that purpose built hardware can always scale and outperform software running on general purpose hardware. I don’t know if I buy this argument any longer. Scott Shenker from Stanford gives a great argument how x86 based controllers can perform just as well as ASIC based controllers. And again since we are talking about two products that haven’t been released yet this is all theoretical. In theory, VMware’s partners can build ASIC support where needed. I compare this directly to how Intel and AMD have built virtualization assistance in their chipset over the past few years to close or all out eliminate the performance delta between physical and virtual machines. F5 for example has announced at VMworld tight integration with NSX.
Again, for a real world perspective, VMware has legacy customers running Nicira at what I assume is scale. Cisco has proved itself as a network hardware provider that can run the largest workloads on the Internet, so I have little doubt when ACI hits the market that they will be able to deliver on their promise of scale.
This is maybe Cisco most legit argument against the software first approach but also one of the most difficult ones to support with publicly available information. I’ve questioned in the past the amount of overhead associated with managing both an overlay network and the underlay physical network. The networking team still needs to support the full range of IP and physical infrastructure associated with the physical network as well as the overlay network. The approach does give organizations the option to outsource the physical network in a similar fashion to how MPLS is done today. However, the difference is that the enterprise network is homogenous. There is and will still be a need to connect physical nodes to the physical network. There will be the need for the physical network and virtual network to share subnets and VLANs. This makes the wholesale outsourcing of the physical network impractical if not impossible.
That leaves the enterprise network team to manage the complexities of two logical networks. Cisco’s claim is that their ACI approach is one system. Administrators can use the same tools they use today to manage their SDN network if they base it on the ACI architecture. This sounds reasonable except we don’t have enough detail to know how a reference ACI network would look like in the wild or what the operations model would look like from a practical sense. We know conceptually you can leverage your existing Cisco Nexus environment along with the added software components but we don’t know what a network would look like functionally.
We do know what the Nicira network looks like in production. VMware produced a great piece that looks at the challenges and approach to debugging a virtual network. It helps to show that real thought needs to be placed into the design and management of the network prior to deploying it to avoid specific pitfalls associated with virtual networks.
Cisco’s additional point in management overhead is change management when going with a software first implementation. One of the advantages of box to box communication is that it relies on protocols instead of API’s. When say your hypervisor vendor updates their code there’s a perception of higher risk to the API’s breaking vs. when a network vendor updates a box and the protocol not working. From my experience of managing servers, I have to say this is an area of concern. When you talk about multi-hypervisor support there is just something more comfortable with me switching out a box based on protocols vs. installing a new software stack based on API’s and counting on my system still functioning as expected.
I don’t share Cisco’s concern with Multi-hypervisor support or scale. I believe VMware’s hardware and software partners will eventually work these issues out where they exist. I do however have reservations when it comes to the management overhead associated with a software first approach. At the end of the day I keep coming back to the fact that VMware has real customers running Nicira in production while Cisco’s ACI is a great concept that’s still on a whiteboard.