Software Defined Networking – The policy, programmability and bedlam as VMware NSX prepares for public release
These are very exciting times in virtualization as we prepare for the general availability launch of VMware NSX, the product of the Nicira integration over the past 14 months. The product received heavy focus at this year’s VMworld in San Francisco, so much so that it was referred to by many as “NSXWorld”.
I’ve been lucky enough to have some exposure to the product through a few different channels, and the product is very exciting. But with this excitement comes some trepidation by many as to how it will become a part of the customer ecosystem.
The reason that I have titled this to include the word bedlam is that there is a lot of really wild swings in opinion on the upcoming GA release, and how NSX will become a part of what we do today. Even beyond NSX, SDN in general invites some strong and often misguided opinions on either side of the argument for what it is, and why it is a forward thinking and inevitable shift in how we manage our networks.
A Key Point of NSX and SDN
The phrase SDN (Software Defined Networking) gets thrown around a lot, and sometimes incorrectly. Just like the use of the term “cloud”, there are some basic tenets that define a SDN product but the most notable is the separation of the data plane from the control plane.
This means that the underlying infrastructure and physical characteristics of networking are still present at the data plane, but the control plane is software managed, programmable and abstracted from the physical infrastructure.
What is a really big draw for this is the escape from hardware vendor lock-in. There will be more chat further down. One thing that cannot be denied is the buzz around what VMware is doing with NSX, and how much interest it is raising. The VMworld San Francisco Hands-On Labs were dominated by the HOL-SDC-1303
There are some key people who began in Nicira and brought NSX into the VMware family through the acquisition last year. To start with, you may know folks such as Martin Casado, a significant player in the creation and growth of OpenFlow. Or perhaps you’ve heard of Bruce Davie, who among many accomplishments was involved in the architecture of a little thing called MPLS. Maybe you’ve heard of Ben Pfaff who was the lead developer on the Open vSwitch project.
The list goes on, and the people involved have a common theme. They were responsible for bringing game-changing networking technologies to the market. Nicira was a disruptive and innovative company on its own, and the merger with VMware has the potential to create a real juggernaut. This isn’t a fly-by-night operation that just hit the silicon valley with a little bit of VC money to create a marketing machine without any innovation behind it.
Policy and Programability
Possibly the most important feature of SDN is the policy management and programability of the networks through the use of SDN. By that, we mean that the deployment and management can be done through orchestration and automation to add network policy management into the deployment pipeline.
The exposure of APIs (RESTful is ideal) has become the top feature in being able to orchestrate the network features in our virtual and cloud deployment workflows.
Better Controls not Less Control
It gets tiring to hear the argument between network admins and sysadmins over who will be managing the infrastructure components as network virtualization becomes widely used. There are going to be clear delineations just as there are today. We won’t have sysadmins wildly creating networks and reorganizing the topology. Just as we will not have network admins drilling down into the VM networks to change designs and policy on the fly.
If you lack the controls to manage your environment today, network virtualization will not save you from it. If anything, it will highlight that you have an issue. The goal of any NV deployment is to enhance the ability to delivery policy and features programmatically which simplifies your change control and separation of administration.
The polices are created by people, and the system applies them through orchestration and/or centralized management tools. The control lies in the fact that the policies, and the application of those policies is done using a system. That system allows for stronger controls, auditing, and logging.
This is probably one of the biggest questions that is floating around even beyond the technical viability of the product. The truth of the situation is that it will be a non-trivial capital cost to you for running NSX in your environment. Many SMB (Small to Medium Business) customers may find themselves priced out of NSX at launch. Many SMB folks today don’t even have vSphere Enterprise Plus or vCloud deployed.
Cost will be a strong factor in defining who the target customer is for VMware NSX. If bringing vCloud into your shop is already a limiter because of cost, then we can be sure that this will take some serious thought and justification. That is the capital cost side of things at least.
There is an intangible cost that comes with having, or not having a technology such as NSX in your environment. That comes with the processes and efficiency that you are able to gain by adding orchestration into your network infrastructure management.
Breaking the FUD
There are some really strong opinions for and against what is being done with NSX as it prepares for GA release. Much of the challenge from industry pundits comes as hardware vendors and ASIC providers present the case that using software abstraction creates overhead, and thus lowers the efficiency.
The truth about overhead: it exists. The real question that we have to ask ourselves is whether the challenges with overhead are outweighed by the effectiveness given with creating a singular, programmable ecosystem in which to manage your network platforms.
Is your current production workload maxing out your physical network infrastructure? If so, you need to rethink your architecture anyways. The addition of network virtualization won’t be what tips the scales towards or against your infrastructure issues. Bringing NV into your environment is going to be a fundamental shift in the way you manage your networks which is the both the cause and result of what NV does for us.
Another classic that we hear is “so do we have to get rid of our physical networking gear?” Seriously?! If this is your argument then you need to back up a bit and think about what network virtualization does. If you have 700 physical ports lit up today with your bare metal infrastructure running your virtualized and physical server environment, you will need 700 after you deploy NSX.
What about Cisco being noticeably absent from the partner ecosystem diagrams during VMworld in San Francisco? The truth is that we are reading much more into it than we should. There are indications of some exciting news coming from Cisco and VMware on innovations soon, so this may just be like the Oscar speech where the actor forgot to thank the assistant director and viewers think it’s a snub.
“Network virtualization will reduce my FTE (full-time equivalent) count which could affect jobs” is another one that I’ve been hearing. This is as old an argument as the “robots will replace workers in manufacturing”. So far, automation, orchestration and virtualization of physical infrastructure hasn’t reduced jobs. In fact, it may have not just increased the number of jobs, but the quality of those available.
Are we just moving from hardware vendor lock-in to software vendor lock-in?
This is the nub of the argument. The pro-SDN camp is pushing the concept of escaping vendor lock-in. But if we are fully diving into using VMware NSX in our environment as the SDN technology of choice, aren’t we just moving to a vendor lock-in at the software side.
It’s a valid argument, but the tipping point for me, and many others is that the change in process and methodology is the real innovation that is coming with SDN. Technology is the enabler, not the goal. The goal is to fundamentally change and improve network management and deployment.
Understand the Use-Case
The core and fundamental requirement of bringing network virtualization into your environment is mapping the use-case against your business. If you are still not at a point where you are orchestrating and automating significant portions of your infrastructure, you may not gain significantly from adding NSX or any NV product into your toolkit.
The addition of NSX as an option in the virtualization world is a clear and solid step towards wider adoption of orchestrated infrastructure and abstraction of the physical infrastructure away from your network operations. You may not be hitting F5 in your browser every day looking for the GA code and price list on the VMware website, but ignoring what the release of this product means to the industry as a whole is the same as when this quote came out:
[quote]”As nice as the Apple iPhone is, it poses a real challenge to its users. Try typing a web key on a touchscreen on an Apple iPhone, that’s a real challenge. You cannot see what you type.” – BlackBerry (formerly RIM) Co-CEO Jim Balsillie, November 2007.[/quote]
Even if you don’t plan to deploy NSX at the launch, you should be ready to look at how the paradigm shift can bring your network and virtualization practices to the next level. It is as important to understand why you may not need this as understanding why you do.
Getting to Know NSX
There is one great way to start, and that is with the VMware Hands-On Labs HOL-SDC-1303 that you can do online:
Plus, there are numerous resources on NSX at the VMware Network Virtualization blog: http://blogs.vmware.com/networkvirtualization as well as lots of other resources on NSX and NV in general:
- Brad Hedlund – http://bradhedlund.com/
- Scott Lowe – http://blog.scottlowe.org/
- Network Heresy – http://networkheresy.com/
- Martin Casado’s VMware blog – http://blogs.vmware.com/vmware/author/mcasado
Start there, and let’s see what NSX will do for you in your organization.