New software networking products are coming to market at an increasingly rapid pace. While Vyatta was first (by years), a slew of virtual and SDN-related solutions have been announced over the past few quarters, including within the category of virtual router. It’s easy to get confused over how all these products impact the march to SDN architectures.
For example, there is a bevy of security virtual machines in market now. Research firm Infonetics estimates the market for VMs that perform firewall, VPN, IDS/IPS and content security is roughly $1B currently.
However these are Layer 4-7 products, delivering functions that make the network better. The base configurable network is Layer 2 and 3. That’s why in the traditional hardware networking market the L2-3 space dwarfs L4-7 by roughly 5:1. So in software terms, the march to SDN needs to focus on the L2-3 space, with the latter being defined by a virtual router.
Today the vast majority of virtual routers are deployed in Virtual Data Centers (VDC) and Cloud Service Providers (CSP). This is highly correlated with the fact that these are the most highly virtualized production environments; and when there is application VM density there is the need to manage the traffic between those VMs. That’s the job performed by switches and routers – or in software terms, vSwitches and vRouters.
As every hypervisor already has a vSwitch, the first actionable step for customers in driving to a SDN architecture is selecting and implementing vRouters. What is the difference between the vendor options? And how do those differences relate to the virtual environment requirements? The wrong choice can severely impact your IT strategy by throttling performance, limiting agility and even limiting the kinds of compute environments that may be desired.
Performance is enabled by the vendor - either through know-how or desire. It takes time for a vendor to work through the different challenges that stand in the way of router performance in a virtual world. A recent NetworkWorld article highlights the substantial differences that can exist between virtual routers.
If you are evaluating a virtual router from a vendor that sells hardware routers, beware their lack of desire… the faster their virtual router goes the more they cannibalize their expensive hardware routers. Their only option is to make the virtual router go faster, but charge an outrageous amount for it in order to cover their lost hardware revenue. (For more on this, see guest blog on SDNCentral.com titled Software Centricity and the New Normal.)
Obviously, artificial performance throttles put in place by the vendor also impact your infrastructure’s agility. Buying with headroom to grow is a big part of that.
Agility and choice are also reduced if the vendor limits the deployment environments. For example if the vRouter is tied to a specific vSwitch, that can limit your hypervisor choices – and even your entire cloud computing architecture. If you are building a hybrid cloud (your own VDC with linkages into a CSP such as Amazon) you need your vRouters to be deployable in both environments.
So in the march to SDN, keep these reminders in place:
Immediately accelerate your plans to extend your L3+ capabilities into your virtual server environments
Make sure you’re choosing a vendor that gives you near-term headroom to grow from a performance standpoint, in a way that isn’t cost-prohibitive.
Hedge your bets by ensuring your vRouters can be deployed in any environment
Keep your eyes peeled for architectural locks. They often take the form of a protocol, software widget or API proclaiming its “differentiated value” when in fact that piece prevents you from maintaining vendor choice going forward.
In a virtual world, there are new things to consider when making vendor choices. Keep your options - in a word - "open."