Two steps forward, three steps back

Every time there is a major shift in technology thought about architecture the question of how it will and should impact infrastructure arises. When SOA was the “next great thing” there was a spate of announcements regarding how infrastructure would not only support it but integrate into its ecosystem. This time it’s virtualization, and its impact on infrastructure both from a support standpoint and usage is getting a lot of mindshare. In a recent announcement around virtual network infrastructure Om Malik of GigaOm has some interesting commentary:

As we’ve outlined in the past, virtualization is going to force networking vendors to change. There were two scenarios that we outlined; one was that networking vendors could shift their business and sell to cloud operators — Cisco is doing that with its unified computing efforts.

The other option was for routers, load balancers and firewalls to run inside the “virtual appliances.” Some believe that the routing, blocking and distribution of traffic can be done well in a “cloud environment.”

It is the second option that keeps cropping up as more and more attention is brought to bear on the importance of infrastructure to emerging data center models. The problem is that it isn’t as easy as it first sounds to just pack up the software that powers hardware-based network infrastructure and replant it inside a virtual container.  There are both advantages and disadvantages to such an approach, and it’s important to examine how virtualization might affect the capabilities of infrastructure when moved to a virtualized environment before blindly accepting it as an option. 

The first problem is what to do about hardware acceleration. That would be primarily SSL and compression. Obviously if you’re running inside a virtual container you can’t rely on the existence of such specialized hardware and, in many cases, couldn’t take advantage of it even if it did exist.

Back in the old days of SSL now defunct companies like Rainbow and nCipher sold SSL acceleration cards. These cards were PCI-based and slipped into just about any server hardware you had. The trick was to get the software – primarily web and application SSLcard servers – to be able to take advantage of the hardware accelerated functions for bulk encryption and SSL handshaking. This was accomplished via what was called “drivers” but in reality this was a misnomer. They weren’t really drivers as much as they were plug-ins that essentially replaced the libraries used by the web/application servers to provide the bulk encryption/decryption and SSL negotiation functions. These plug-ins were provided by the SSL acceleration vendor, not the software vendor, and thus supported a very limited set of web and application servers.

Over time the effort and cost of managing SSL acceleration cards in every server in a data center grew too unwieldy and was moved to an “off box” solution. Imagine trying to maintain a data center with even a hundred servers, each with an SSL accelerator card and each requiring upgrades, patches, and management and you’ll see why folks moved to off-box solutions. These “off box” solutions eventually merged with load balancers and SSL accelerated functions are now offered by every vendor offering a load balancer or application delivery controller solution.

So why couldn’t we just go back to the old PCI-based server solution? We could, if there was a way to “plug-in” that functionality to web and application servers – and every other piece of software out there that needed it. Now Microsoft’s CryptoAPI is often used by software for such tasks, replacing its core encryption and SSL functionality with one that took advantage of acceleration hardware – when it was present – would provide a nifty, neat and simple solution. But that’s only Microsoft-based servers; that leaves quite a number of solutions running on Linux and Unix out in the cold. And of course it returns us to the days of decentralized certificate management and all the additional burdens that a virtualized infrastructure brings to that mess including an increase in operational expenses associated with managing decentralized certificates.

Too, there is the issue that there’s never been a server solution for hardware accelerated compression. That’s not to say it can’t be done, but someone would need to provide that one if there was a call for it. Granted, SSL and bulk encryption/decryption is far more widely utilized and therefore likely the most important piece to provide first, but compression should certainly be considered as a second in line as the improvements in performance and resource savings from utilizing hardware assisted compression are noticeable enough to make a difference.

But until such solutions appear, moving network infrastructure to “virtual appliances” effectively wipes out the benefits of hardware-assisted acceleration of those functions, which means the equivalent solution in a virtual appliance is necessarily going to suck up more server resources which is going to translate into needing, well, more server resources. The average resource savings per server from offloading SSL to a hardware assisted device is 30%. By eliminating that savings you effectively need 30% more resources on a virtual network solution as compared to a network device. That’s likely going to result in an increase in the number of instances you need to deploy a similar network infrastructure in a fully virtualized architecture.

Perhaps even more important to network infrastructure is control over the network stack. Most network infrastructure that has completely given over to hardware integration – routers, switches, some application delivery controllers/load balancers, and storage solutions – do not rely  upon a “standard” TCP/IP stack. Instead they have a completely custom TCP/IP stack that has been expressly optimized for the specific tasks for which the solution is geared. Simply shoving the entire solution into a virtual appliance necessitates that it uses the virtualization provider’s TCP/IP stack, which means any benefit provided by the custom TCP/IP stack is immediately lost. That generally results in performance degradation as well as a reduction in overall capacity.

Now, luckily virtualization providers recognize the need for some solutions to bypass their network stack – for control, for performance, for whatever – and have the means by which third-party developers of software can route around the virtualization solution’s stack and use their own. In some cases the developers can go straight to the hardware in question without needing to implement what is essentially a “plug-in” replacement of the virtualization solution’s stack.

But this takes time, and it isn’t completely a panacea as there’s still the little issue of limited throughput (you’re reducing something originally meant to handle many ports to something with one or two or five) and the complications of trying to route through virtual switching technology. It can also seriously impact capacity as you’re now running in a virtual environment that’s likely more limited in terms of CPU and resources than what that infrastructure was used to having at its disposal in its native hardware environment.

So vendors either take the time to do it – assuming they can - or they don’t and in the process lose a lot of hard-won advances in technology regardless.


At the end of the day (as long as I’m used tired, worn-out phrases) there are definitely advantages to a virtual network infrastructure. Scalability becomes a matter of just firing up new instances, just like applications, though it is important to remember that Confusedscalability is not infinite. There are limitations based on your budget as well as physical limitations imposed by the size of the provider’s data center. Still, scalability is certainly perceived as being easier with a virtual network infrastructure as long as there is physical capacity, and it is unlikely a provider, at least, will run out of physical capacity. Automation of scalability of the infrastructure, too, would provide benefits not available with a physical deployment as the latter requires a physical device be racked and powered on while the former is more likely able to simply be “powered up” on an existing server. Control and management are infinitely easier from both the provider and the customer’s point of view with a virtual appliance model as it is completely left to the customer to configure and manage, and multi-tenant management in network infrastructure is still maturing.

What you’re most likely losing is reliability of the hardware as well as capacity and performance improvements from a flatter architecture and the inherent gains available from specialized hardware. Availability, too, may be impacted. As noted recently by analyst John Abbot of the 451 Group in his report, “Break Point – Virtualization and Availability” there is a danger in starting a virtualization project without an availability strategy because the likelihood of downtime actually increases with virtualization because more work relies on fewer (physical) servers.

The question of what is gained by a move to virtual network infrastructure is also rarely addressed. Network architects are certainly going to be loathe to deploy critical network infrastructure in a virtual machine that is shared by…anything else. A dedicated server would likely be required, which then begs the question why one would swap a dedicated piece of hardware for a dedicated piece of hardware. Sure, the possibilities of sharing resources sound good, but when we’re talking critical network infrastructure that’s something unlikely to happen unless it’s absolutely necessary.

So while core network infrastructure services certainly can be made available and deployed as a virtual infrastructure, the question is whether the benefits balance out the negatives or not. Comparisons of performance and capacity between hardware and software solutions already provide some baseline for understanding just what those negatives are and whether the costs for software to match hardware in a virtual infrastructure would end up justifying the investment in a hardware infrastructure or not. The equation is likely highly dependent upon whether you’re a cloud provider or an organization looking to implement an on-premise cloud architecture, as the former has little impetus to reduce the number of instances required for your environment to run in the cloud (more instances means more revenue, after all) or invest the time to leverage existing capabilities to provide better control for customers over the hardware-based infrastructure.


Follow me on Twitter View Lori's profile on SlideShare friendfeedicon_facebook AddThis Feed Button Bookmark and Share