NSX is now a proven technology that really increases the network reliability by introducing an overlay and reducing the overhead for secure VM to VM communication (East-West traffic). VMware started selling this product as a component for vSphere environments: in addition with vSAN and in vCloud Director environment, VMware becomes more and more the reference technology for service providers and building-block oriented data center.
The introduction of a multi-hypervisor version for NSX, called NSX-t has shuffled the cards again: leaving the status of vSphere dependent component, this NSX version become a stand-alone networking product for virtual and physical environment and containers. Let’s see in depth.
Should we need NSX-v in vSphere environment?
The recent attacks against virtual environments and private/public cloud demonstrate that the security is a concept not well spread across the CTO’s minds.
If you invest a lot thousand and thousands of bucks in a single and expensive firewall, probably you’re missing the visibility and the control inside the workload. The recent attack backlogs show the applications inside the “safety area” as the root of the breaches.
Is true! The reason for this lack is due to wrong confidence in the running applications.
NSX-v takes care of East-West security, by the introduction of the Distributed Firewall/Routing and VXLAN overlays (Logical Switches). While in the traditional (old) network design a big firewall was taking care of every packet is flowing from every virtual machine, the new vision of network made by NSX realizes a better security level acting at the hypervisor level, without wasting resources and bandwidth for network security. In the same time, the tenant isolation and automation are kept under control by a single point of delivery and control. (Freedom and control)
The Container Quest!
Containers are becoming the new “way” to deliver last generation apps made by discrete pieces of code called microservices. In this scenario data and connections tenfold capacities and connections to ensure better customer usability and experience through mobile, wearable, IoT controllers and so on…
By this architectural change, developers and IT operators are now happy to break the boundaries from the underline infrastructure. But:
- The security trust VM to VM must be transported at container level even if they are in the same VM
- Even if containers are isolated by design, new kinds of attack could affect the data center if a single container is violated.
- From the infrastructure guys perspective, containers are generating “a dark side” of the network that could not well surveilled by the system or network administrators.
Security could compromise the container adoption in many companies, and this could represent a resistance that could drive to a loss of opportunities and money.
Could network overlay and in particular NSX, address this issue? and how?
VMware with vSphere Integrated Containers has provided an environment where sysadmin and Dev-Ops can stay without fighting. This solution provides a simple 1:1 container-VM creation starting from a “mother” VM and every child VM is a VM that runs a single container. In this way, every connection between containers is forces to flow across VM through virtual or NSX logical switches inside the same vAPP. ( https://www.vmware.com/it/products/vsphere/integrated-containers.html )
But some environments have already delivered their container in “classical way” and increasing the overheads could result inefficient.
Should NSX-t the future?
In my opinion yes!
Finally, there’s a standalone product, able to realize this network overlays environments like Hyper-v, KVM, physical hosts as already done in vSphere. The good news is the native support for container networks, that really gains the missing visibility of seen before.
One Software-defined network platform for every environment!
For these reasons, there is the suspect that this product will replace NSX-v… but with some points of attention:
- NSX-v and NSX-t are not the same product: the underline concepts respect the paradigm, but upon architecture has new concepts and new ways for being implemented.
- Price and cost model could be different and subject to change… This sometimes could drive the adoption, especially by service providers.
Recent announcements about version 2.3 see the extension of the support of NSX in the bare metal servers running CentOS, Ubuntu, and RedHat. The network extension to a public cloud like AWS and Azure brings the network governance to a higher security level that is difficult to reach with the traditional architecture. In this way, the security and the portability of the application between private and public cloud are becoming reality.
Security is not an optional thing and new regulations are driving every company to a by-design approach that discourages the adoption of potential failing systems and applications. During my experience, NSX becomes a powerful ally to increase the security without compromising the efficiency and the freedom to create applications and environments for my customers.
This natural evolution could represent what people are looking in a software-defined network platform that should improve the infrastructure, especially when the security is automatically ensured at every infrastructure change.