Network Virtualization isn’t Vaporware

Flying Cars! Where's my Flying Car!
Flying Cars! Where’s my Flying Car?

After writing a post on SearchNetworking asking the question if Network Virtualization was Vaporware, I got a lot of feedback.  Much of it asking me if I am crazy and where have I been for the last couple of years.  There are implementations of OpenSwitch that reaches the 10’s of thousands of nodes.  The idea of the post was to poke a bear so to speak.  I know full well network virtualization in itself isn’t vaporware.  The number of virtual ports exceeded the number of physical ports back in 2010 I believe.  There’s no question that the network virtualization is real and is a serious force in the market.

The question was more geared toward asking when will the virtual and physical worlds  merge?  Specifically, I was looking for a single feature that I believe has a ton of particle application and that’s the ability to “virtualize” a single port on the underlying physical transport.   This would be the ability to extend my virtual switch to manage a physical port as if it were a virtual node.

In my ultimate vision of the virtualized network, the network hypervisor manages both physical and virtual ports.  At first blush you might ask the question why is this even a practical design need?  I believe it’s the same argument some people use against the Software Defined Data Center (SDDC) architecture VMware pushes.  The basic premise behind the SDDC is that you design a data center from a virtual first approach.  Everything in the data center is controlled via centralized control platform (now you want to talk vaporware).  The more virtualized your data center, the better opportunity you have to manage it using software.

This can be a difficult end state to achieve.  Unless you no longer have need for workloads that can’t be virtualized, you will still need to manage the physical ports of those devices.  Most organizations I encounter are nowhere near able to perform the level of re-architecture required for this design.  They have legacy systems and processes that cannot easily be re-engineered and migrated to a virtual platform.

In addition, it’s impractical to virtualize some workloads.  So, for most organizations this leaves a requirement to manage two endpoint networks in their data center in addition to the physical underlay of the virtualized network.  The VMware Networking team wrote a great post on debugging your virtual network over on Network Heresy(warning if you find the post you are reading geeky then good luck with getting through the aforementioned post).  From the post you can tell that it’s important to have solid separation from the underlying physical network and the virtualized network.

So, I’m holding out hope that one of the big features of NSX (VMware’s Network Hypervisor) is that it controls both virtual and physical ports alike.  I’m not glossing over how complicated a challenge this is for VMware of any other vendor for that matter.  But, I’m hopeful given VMware’s advancements with x86 virtualization.  I glossed over some operations stuff I had from my first x86 virtualization environment running in ESX 3.5 vs. the features added to vSphere 5.1 and I have to tell you that if any vendor on the market is capable of the disruptive spirit needed to tackle such a big challenge the team at VMware/Nicira should be able to accomplish it.  No pressure….

Related Posts

Network Virtualization as I Understand It

Published by Keith Townsend

Now I'm @CTOAdvisor

4 thoughts on “Network Virtualization isn’t Vaporware

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: