Which NSX version is the future of SDN? NSX is VMware's SDN play and offers an easy-to-use, color-by-numbers system for both specialists and non-specialists.
VMware's NSX versions do SDN in an easy-to-use fashion, but it relies on third-party offerings to fill in some major security gaps.
Software-defined networking (SDN) is a buzzword for the automation of networking, and NSX is VMware's SDN play. NSX, which incorporates elements of network function virtualization, has two versions: NSX-V and NSX-T. Although other applications, infrastructure components or services can provide all the network services that NSX does -- such as virtual routers and IP address management -- NSX orchestrates some networking items and provides several network services.
Much of the confusion surrounding NSX has to do with how different groups of IT administrators and developers perceive it. To networking admins, NSX looks like color-by-numbers networking for people who don't actually know networking. To non-networking specialists, NSX can look like networking for people who simply don't want to know networking.
Color-by-numbers networking
NSX isn't a replacement for all the services traditional networking vendors provide. For one thing, NSX uses network overlays, which run on top of a physical network. NSX doesn't control the physical layer -- at least right now -- so companies still owe the tin-shifters a tithe to build the physical network fabric that NSX uses.
The big physical networking vendors also tend to have more serious network security offerings, which can include firewalls, load balancers, proxies, intruder detection systems, monitoring tools and analytics.
Both NSX versions offer many of the basic network services, such as firewalls and load balancers, but they still rely on third parties to provide advanced network services. More simply, NSX can stand up network plumbing for workloads spanning multiple physical locations on different infrastructures. However, to really dig into what flows through those pipes, NSX must call a friend.
Security and microsegmentation
For many networking specialists, NSX might feel like a toy. Their existing stack can do everything NSX can do and then some -- so why change?
NSX can stand up network plumbing for workloads spanning multiple physical locations on different infrastructures. However, to really dig into what flows through those pipes, NSX must call a friend.
There's a lot wrong with this point of view. There are alternatives for everything NSX can do, but in some cases, NSX just does them better. Microsegmentation is one example.
There are many approaches to microsegmentation out there, and many vendors have chosen a firewall orchestration approach. Such microsegmentation vendors insert an agent into the OS of tasks and control the firewall of a task's OS to create microsegments. The firewall orchestrator denies all traffic except what's required for a task to communicate with other tasks.
These workloads must also be explicitly defined in order for them to communicate. This is useful, but significantly inferior to what NSX can achieve.
NSX microsegmentation isolates workloads into Virtual Extensible Local Area Networks (VXLANs) -- like Virtual LAN, but for grown-ups -- and then puts a firewall at the edge of the VXLAN. In addition to the firewalls on the individual workloads, the VXLAN and the microsegment edge firewall add layers of protection.
If a workload is compromised, its firewall becomes compromised. It can then attempt to communicate with, hack and infect anything else on the network. Some workloads -- hopefully most of them -- can be protected against attacks using firewall orchestration, but many devices and OSs can't be managed with firewall orchestration tools.
Segmenting tasks into their own VXLANs means that they can only communicate with the other tasks in the VXLAN -- tasks that are usually part of the same service -- and whatever the microsegment edge firewall allows. This dramatically reduces the number of actions a potentially compromised task can even attempt.
More importantly, NSX makes network orchestration easy enough that admins don't need to be network specialists. Generalist IT administrators used to looking after virtualization infrastructures and OSes can build an automated, secure SDN with NSX. The ease of use really does matter.
NSX-V versus NSX-T
NSX can't do many things that classic networking products do; there's no getting around that. But NSX integrates with many of those classic networking products. It orchestrates not only its own features and services, but those of third-party products, as well. In a sense, NSX is to networking what cloud computing is to basic IT infrastructure -- it offers orchestration, automation and self-service.
More pointedly, NSX is the future -- or at least a good idea of what's to come.
Still, NSX has a problem. It's actually two distinct products with two distinct code bases: an NSX version for vSphere (NSX-V) and an NSX version for everything else (NSX-T). NSX-V has more features than NSX-T, but NSX-T integrates with vSphere and supports ESXi, KVM, bare-metal servers, Kubernetes, OpenShift, AWS and Azure.
If all features were equal, NSX-T might seem more attractive. Support for multiple infrastructures is better than support for only one. Unfortunately, there is a feature gap between NSX-V and NSX-T.
Despite rumors about VMware folding NSX-T and NSX-V into one product, the different codebases make that unlikely. NSX-T might eventually reach feature parity and eclipse NSX-V. Equally likely is that both applications will evolve on their own paths to meet different needs for different customers.
NSX-T is the future of NSX
NSX-T supports container platforms, bare-metal servers and major public cloud providers, whereas NSX-V doesn't. NSX-T also supports modern, cloud-native applications in ways that NSX-V can't.
The hybrid or multi-cloud approach is the inevitable future of IT. Vendors build multi-cloud management systems that can orchestrate task placement across multiple infrastructures in an automated fashion.
Multi-cloud management applications that can instantiate workloads on different infrastructures and migrate tasks between them as necessary will likely define the 2020s. These applications tell organizations how much on-premises infrastructure they need to meet their configured policies, regulatory requirements and rent in the public cloud.
SDN products stitch together those hybrid and multi-cloud applications. As the management applications become more capable and accessible -- and, thus, more popular -- SDN adoption will increase in smaller organizations.
NSX's lead over competitors with roughly equivalent products is currently substantial. This leaves room for other vendors to try to oust VMware by offering a more capable product, but the clock is ticking. The longer that VMware lays claim to the ease-of-use crown, the more embedded into the industry VMware's approach will become. Once one of these NSX versions becomes the default SDN, it will put everything else at a severe disadvantage.
