Sergey Nivens - Fotolia


Blurred lines: Who will own the VMware NSX platform?

Using VMware's NSX to lift networking functions from hardware brings with it questions on which team should step in when "the network" has issues.

Technological advancements have a way of disrupting the industry where they are implemented and the IT organizations that adopt them.

For example, take server virtualization. With virtualized servers came virtualized switches, which put stove-piped server administrators in the uncomfortable position of managing networks -- or at least handling network-related things. For IT shops clinging to the three-silo model of server, storage and network teams, server virtualization forced server and network engineers to negotiate a new point of demarcation. Physical networking was largely unchanged, but all things virtual -- with the rare exception being the Cisco Nexus 1000v that no one wanted and even fewer people used -- became the domain of the server team.

The same story can be told of storage. The Virtual Machine File System abstracted storage so well that storage administrators completely lost track of the workloads they were supporting. And instead of your SAN team being involved in the deployment of every new server, server virtualization saw the advent of near-instant virtual machine instantiation, with no feedback -- save for the slow uptick of IOPS -- provided to the storage engineers.

In both cases, VMware's vCenter Server provided a consistent context for the administration and management of virtualized servers and abstracted storage. Because the services model was server-centric, the server team naturally picked up the responsibility.

When virtualization is server-centric, the server team is the understandable owner of the technology. There is also a clear hand-off between teams -- network team provides VLANs, storage team provides LUNs -- if you'll forgive the oversimplification. The premise is your organization insists on isolating technologists in neat little boxes that only make sense to someone with an MBA.

NSX presents a puzzle

But what happens when virtualization is network-centric? What if, instead of virtualizing x86 servers to release them from their physical prisons, we're virtualizing networks? The organizational waters grow murky at the mere mention of the VMware NSX platform.

When you own the hardware that's central to the technology, the onus falls to you. But this presents a problem: network virtualization, as implemented in NSX, is network-centric -- but server-driven. You don't load NSX on your existing switch infrastructure; you layer it on top of your established vSphere deployment. So with the prospect of managing your virtualized network from a mesh of instinctually opposed engineering teams, you've got to keep three things in mind:

  1. Role-based access control (RBAC) is a double-edged sword

You may be tempted to address the server vs. network debate by implementing RBAC to cleave operational responsibilities into two or more equal parts. VMware NSX facilitates such a configuration, with built-in roles that range from the read-only auditor role to the unfettered god mode of enterprise administrator. But tread carefully: in the process of narrowly defining administrative access to NSX, you can end up reinforcing the server vs. network conflict, instead of embracing a matrixed -- or hybrid -- approach to your operations. Keep in mind that the technology that supports contemporary infrastructures is converging; it stands to reason that your engineering teams should be converging, too.

Instead of simply overlaying RBAC on your org chart, send your teams to the NSX troubleshooting and operations class. Not only will you ensure that operational issues in either physical or virtual network can be quickly resolved, but you'll give your teams a common vocabulary to use when collaborating on all things NSX.

  1. Blaming the network on a whole new level

I won't bore you with a litany of ridiculous IT problems that have been blamed on "the network."

But I will take a moment to remind you why we love to blame the network: Because the network is the only commonality in today's infrastructure. And we use the term "network" so loosely that it can mean almost anything, from a disconnected cable to a munged border gateway protocol table.

VMware NSX, like other overlay solutions, layers virtualized networks on top of the physical network. The technology here is sound, but the impact of network overlays on your operations team, with particular regard to diagnostics and troubleshooting, is non-trivial. The traditional troubleshooting method of working your way up the Open Systems Interconnection stack runs afoul once the network engineer's tools lose visibility into the overlay network. And your NSX engineer's troubleshooting may be hindered by poor visibility into the health of the underlying physical network infrastructure.

Worst case scenario: your physical network team and your virtual network team blame each other. "Our network is fine. It must be their network."

Avoid this situation by deploying a robust monitoring product to check the health of both your physical and virtual networks. Bonus points if you select something that isn't developed and sold by Cisco or VMware; pick a third-party player to be an objective source of performance and health information for your environment. Doing so will put the focus on the alerts and events that can lead your engineers to the root cause and resolution of problems, which all but removes finger-pointing.

  1. Know your problems

It's easy to get caught up in the excitement of NSX. But be mindful of the reason you purchased NSX in the first place. Maybe you wanted to improve your east-west security in your network's gooey center. Maybe you wanted to apply the rapid provisioning you've come to expect from vSphere to your network. Or maybe you wanted to shift the balance of power in favor of your virtualization engineers to give them control to deploy networks, firewalls, and policies as quickly and easily as they deploy virtual machines.

With a clear and concise problem statement, you can very easily determine which team has the most vested interest in the successful implementation and operation of NSX. That's the team that should assume its operational responsibility.

Next Steps

What the VMware NSX platform means for network virtualization security

Certification track for NSX platform has been released

Is VMware NSX all it's cracked up to be?

How VMware NSX network virtualization could change networking -- or not

Dig Deeper on VMware and networking