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.
Share This Story, Choose Your Platform!
Keith Townsend is a seasoned technology leader and Chief Technology Advisor at Futurum Group, specializing in IT infrastructure, cloud technologies, and AI. With expertise spanning cloud, virtualization, networking, and storage, Keith has been a trusted partner in transforming IT operations across industries, including pharmaceuticals, manufacturing, government, software, and financial services.
Keith’s career highlights include leading global initiatives to consolidate multiple data centers, unify disparate IT operations, and modernize mission-critical platforms for “three-letter” federal agencies. His ability to align complex technology solutions with business objectives has made him a sought-after advisor for organizations navigating digital transformation.
A recognized voice in the industry, Keith combines his deep infrastructure knowledge with AI expertise to help enterprises integrate machine learning and AI-driven solutions into their IT strategies. His leadership has extended to designing scalable architectures that support advanced analytics and automation, empowering businesses to unlock new efficiencies and capabilities.
Whether guiding data center modernization, deploying AI solutions, or advising on cloud strategies, Keith brings a unique blend of technical depth and strategic insight to every project.