Is it time for virtual switch abstraction to fade?

There’s an inflection point when a new concept just clicks. It happened to me when I was designing a cloud-based infrastructure for a file transfer application. My initial concepts were within the constraints of the traditional data center. In the data center, internet bandwidth is a system chokepoint.  While a individual server may have a 10Gbps or even 1Gbps network card, data flow is constrained by the aggregate bandwidth of the data center. It’s common for data centers to have a single or dual shared internet connection. A single data center may host hundreds of servers sharing that single exit point to the internet.

I was designing for that traditional configuration when I realized cloud-based instances are designed to take advantage of the scale of a public cloud. While the instance may only have 500Mbps virtual interface, the committed rate to the internet is a full 500Mpbs. The way I designed the infrastructure changed based on the realization.

I had a similar realization during Network Field Day 15. The NSX team was describing how application flows over the virtual network. The team described the interchanges within the hypervisor. The interchange system was called a switch. While not new, the concept threw me for a curve.

I’ve seen virtual switch referenced plenty of times. The abstraction is needed as there’s the potential for a virtual switch to interact with a physical switch. Therefore, virtual machines connecting to virtual switches that may connect to a physical network made perfect sense. The NSX overlay allows direct mapping to the application hosted on the server.

When I heard the NSX reference a virtual switch, something just broke. The switch abstraction no longer made sense to me. What the team was describing was a data exchange service running within the virtual network. All of the network control logic existed in the NSX controller. The NSX controller pushed policy to the hypervisor. The hypervisor implemented the policy on a VM or application flow level.

I just couldn’t let it just go by during the presentation. I asked the team why did VMware continue to use the virtual switch concept within NSX. In AWS, there’s no concept of a switch. AWS doesn’t allow layer-2 protocols. Application developers design IP flows and implement the data flow control via AWS APIs or the control panel.

The discussion completely sidetracked the presentation. However, it’s a great discussion. VMware and by extension NSX is designed for enterprise infrastructure teams to consume. Martin Casado has talked about the need to mature the enterprise network slowly. Abstracting the switch concept to provide data interchange within a hypervisor made sense when network virtualization was a new concept.

At this point, I’d argue that the concept is stale. At least from a flow control perspective. Cloud networking has gone a long way to breaking the mental barrier of new network concepts. I’d like to see what ideas really smart developers come up with when you expose the data exchange control plan to highly parallelized systems.

Beyond developers, forgoing the virtual switch abstraction leads to further integration of cloud-based networking into the enterprise data center. Moving the control plane from something other than a switch aligns with existing cloud models that have been rethought for the modern application design.