Blog Post

Where Are the Network Virtual Appliances?

Stay on Top of Emerging Technology Trends

Get updates impacting your industry from our GigaOm Research Community
Join the Community!

The networking industry is stuck in the 1990s, the last time there was a fundamental shift in commonly deployed network architectures. While servers and applications have gone virtual, migrating into cloud computing environments, networking technologies remain bound to physical hardware and data center racks, creating potential gaps in support or security in virtualized environments. As server virtualization moves into the enterprise and cloud data centers, networking needs to follow with virtual appliances.

Server virtualization uses virtual machines (VMs) to segment a single physical compute server into multiple logical virtual servers. In many environments, collapsing multiple overpowered physical servers onto a single server running multiple VMs can reap significant economic rewards.  A single server consumes less power, take up less space, may be easier to manage and allows for the dynamic creation and removal of VMs on demand.

VMs can be used inside an enterprise IT department or on public clouds, such as Amazon’s EC2.  They can move from one physical or geographical location to another using a variety of tools and technologies, such as Rightscale’s Cloud Management Platform or VMware’s VMotion.  Yet unfortunately, when a VM moves from one location to another, it becomes dependent on the networking infrastructure of the physical appliances attached to the new location.

For the past decade of networking, the basic infrastructure setup consisted of applications running on servers  that were then segmented by switches into virtual local area networks.  Those switches then connected to routers and a potential plethora of appliances, depending on the application needs — physical devices such as load balancers, firewalls, unified threat management devices, Secure Socket Layer accelerators, virtual private network (VPN) concentrators, intrusion detection systems (IDS), data loss prevention devices and so on.

To be sure, some networking devices and appliances are now available in virtual form.  Switches and routers have begun to move toward virtualization with VMware’s vSwitch, Cisco’s Nexus 1000v, the open source Open vSwitch and routers and firewalls running in various VMs from the company I helped found, Vyatta.  For load balancers, Citrix has released a version of its Netscaler VPX software that runs on top of its virtual machine, XenServer; and Zeus Systems has an application traffic controller that can be deployed as a virtual appliance on Amazon EC2, Joyent and other public clouds.

Yet the fundamental problem remains: Most networking appliances are still stuck in physical hardware — hardware that may or may not be deployed where the applications need them, which means those applications and their associated VMs can be left with major gaps in their infrastructure needs. Without a full-featured and stateful firewall to protect an application, it’s susceptible to various Internet attacks.  A missing load balancer that operates at layers three through seven leaves a gap in the need to distribute load between multiple application servers. Meanwhile, the lack of an SSL accelerator to offload processing may lead to performance issues and without an IDS device present, malicious activities may occur.  Without some (or all) of these networking appliances available in a virtual environment, a VM may find itself constrained, unable to take full advantage of the possible economic benefits.

Cisco, the networking giant, has articulated a multiphase plan toward virtual application deployment and network appliances in its Datacenter 3.0 architecture. The company does not, however, offer any specifics as to its time lines for full network virtualization, so it remains to be seen if the industry will wait for the market leader or move to realize the benefits of virtual appliances for networking all on its own.

Such timing is key, in my mind. The networking industry is clearly moving toward virtual appliances; the faster it gets there, the faster applications in the cloud, public or private, will be able to benefit from the same networking infrastructure they currently enjoy in the physical world. At which point networking architectures will change to a degree we’ve not seen in well over a decade.

Image courtesy of Flickr user Joe Shlabotnik.

This article also appeared on

20 Responses to “Where Are the Network Virtual Appliances?”

  1. Is the performance of the virtual appliances that exist today adequate? How does it stack up against the traditional stand-alone box appliance HW solution?

    Historically things that need to go “faster” tend to get their own dedicated solution (e.g. offload/accelerators), that is unless there’s some disruptive technology that changes the game.

    Virtual appliances may truly be needed as cloud/virtualization grows, but is that the only and best option? What if every underlying HW platform (e.g. datacenter servers) had these inherent capabilities?

    • The performance is adequate. VM does not cause drop in performance, except for the HD access (where it drops 2-3x), so that the virtual appliances, that do not depend hard on the HD, are not affected.

  2. @Allan HyTrust is used for a lot of things but on this topic it is used to differentiate network infrastructure appliances from application VMs. As an example an application admin could create, configure and reboot application VMs but not network switch VMs like the Cisco 1000V.

    Another thing I’d like to see is strong hardware accelerator support with Vmotion, HA, etc for SSL/crypto and also for TPM keystores.

  3. IMO the big theme is that commodity hardware is going to be the norm going forward. Compute (as you pointed out), networking (VMs or Linux) seems to be seeing traction in that direction, and increasingly storage (VM or Linux). With ParaScale you can get file-storage(NAS) by ganging together commodity servers and their internal spinning disks ( No question, this is where the world is going.

  4. Could you comment on how this need for all network devices to have a virtual form factor square up with the efforts to standardize on IEEE 802.1Q variants (ah & bg).

    The notion there is that, esp. in an internal DC, instead of having a plethora of enforcement policies, these can still be managed fewer albeit high performance devices.

    • Allan Leinwand

      Agreed – virtual network appliances need to be able to handle multiple VLANs and trunking. Let’s bring on the high performance devices running multiple network appliances!

  5. Yep, true indeed. Confidently, I had this as one of the essential features for Cloud TNG. Except for network services that need wire-speed, all others would move into the “soft-appliance” from factor. Naturally it is not a linear interpolation – the services need to be horizontally scalable, distributable and even inherit some of the protocols that is in the Cloud OS – like gossip, adjacency et al.

  6. Allan Leinwand

    @Will – are you a user of HyTrust or can you cite an example?

    @Matt – agreed. I mentioned Zeus Systems above.

    @Patrick – does VPN-Cubed offer IDS, SSL termination, DLP and VPN virtual appliances? Can you give a customer example that has moved an application that used to live behind these types of physical appliances that has now migrated to the cloud using virtual appliances with the same functionality?

  7. This is why we brought VPN-Cubed to market in November ’08. We have editions that run at Amazon, GoGrid, Terramark, Rackspace, etc.. and connect to your datacenter.

    We collectively have devices that are used at the physical layer (big iron Cisco stuff) by people who provide physical infrastructure, at the hypervisor level (Cisco Nexus 1000V) to help provide virtual infrastructure, but there is a need for devices for users of virtual infra as you point out above.

    That’s what VPN-Cubed is for, giving the cloud user control of addressing, protocol, topology and security – separate and distinct from the underlying layers.