A Networking View of the VMware NSX Platform: Right Problem. Wrong Answer
What a week it has been.
I just spent four long, albeit highly productive days at VMworld 2013 in San Francisco speaking openly with customers, press, analysts and partners. The user conference, now in its tenth year, set a record for attendees with more than 23,000 and we were never without a steady stream of customers and prospects coming to our booth for a demo. Through the hundreds of conversations we had during the week, we found a few recurring themes and questions that bubbled up.
At this year’s VMworld, VMware unveiled a number of new and repackaged products for compute, storage, management and networking, eliminating any possible question about their desire to take over the data center world. What seemed to garner the majority of attention from the wave of press releases was the VMware NSX Network Virtualization Platform. It prompted a ton of questions from visitors to our booth about what it is, what we think of it and how we compete with it (I won’t even get into how many times we were asked: Why do you think Cisco isn’t a partner for NSX?).
There are so many things that need to be discussed VMware’s plans for data center domination that is impossible to write just one blog post to cover them all without writing a novel. The bottom line is, apart from the statement that the network needs to become more agile to support today’s data center, we at Embrane fundamentally disagree with VMware’s proposed approach to building network intelligence as a feature of the hypervisor. As a networking company, we believe Embrane enables customers to build networks the right way for the software-defined data center. We believe it’s important to maintain a clear and healthy separation between the server and network virtualization functions, period.
To some, VMware’s approach to networking may look good on paper, but it will cause more problems than necessary, especially from an operational point of view. For example, the NSX Platform includes working around the network team and asking the systems team to build networks and network security solutions. How is that a best practice? Wouldn’t it make more sense to give the right tools to the network team, which has decades of experience in building, managing and troubleshooting networks, so they can be more responsive and deliver networking solutions more quickly? Personally, when an issue with a network firewall, for example, needs to be addressed, I would rather have the network security experts dealing with it. That’s not an indictment of the systems team either. If something happens to my compute pool, I want them on it, not the network security team.
I spoke with several system administrators who work at big VMware shops about this and they confirmed for me that it’s exactly what VMware is proposing. When I asked them if their network team wants to stop being the bottleneck and be able to deliver network services faster they said absolutely and took my card to give to them.
That’s just the beginning of why their approach doesn’t compute. I haven’t even gotten into the organizational disruption this will cause.
During at least one of the sessions there were comments aimed clearly at Cisco about how this new approach to networking eliminates vendor lock-in – an age-old argument raised by competitors trying to unseat Cisco as the networking vendor of choice. Apparently, asking a customer to base their entire infrastructure on VMware’s compute, storage and networking products is a much more open environment.
As you can tell, there is a definite difference of opinion on how network virtualization should be done. Yesterday, Cisco’s CTO, Padmasree Warrior, weighted in with a perspective that highlights the limitations of a software-only approach to networking. Her argument is that software alone will not suffice to address the rigidity of current network architectures. While her conclusions are not wrong, I believe that the key difference between systems companies like VMware and networking companies like Embrane and Cisco, is not much in how valuable hardware is (I am sure that someone at VMware will soon respond to Padma and acknowledge that hardware matters to them, too), but it’s really about where the network intelligence sits, i.e. in the hypervisor or in the network.
At Embrane we believe that network intelligence should be independent of the hypervisor and enable heterogeneous environment with no vendor lock-in.
We help IT organizations achieve the expected benefits of network virtualization without requiring the forklift architectural change that VMware advocates.
Over the next couple of weeks we’ll be posting new blogs on specific topics related to network virtualization in the data center.
Don’t get me wrong, I absolutely love that the spotlight is shining on the network. But, when you look at a bright light for too long it becomes hard to see. You often need someone to help you navigate while your eyes adjust until you can see things for yourself. I believe you’ll find this series of posts a good resource for different ways to non-disruptively bring agility to your network.
