Network appliances go virtual

January 25th, 2007

Enter any data center and you’ll see a variety of boxes. Most are servers, and most of the rest are “network devices” that are single-function devices for translating and directing flows of bits: switches, routers, firewalls, load balancers, VPN concentrators, compression engines, access controllers, e-mail filters, multiprotocol file servers, and more. These are appliances in the classic sense: pre-defined function, closed operating system, quick installation (usually!) — the opposite in these respects to the applications that run on servers.

The simple installation and operation are clear upsides. Others have listed the downsides of hardware appliances, and they apply here as well: issues when scaling up or down, issues with spare parts and data backups, and clumsy element-by-element configuration changes. Yet for all but switches, their functions can be reproduced in servers with 2 or more network interfaces (NICs) and, usually, open source software. So it’s no surprise that they make popular virtual appliances. In fact, most of the winners of the VMware virtual appliance challenge were network-oriented devices.

A notable example of a classic network appliance going virtual is the Zeus Extensible Traffic Manager. This is a high-quality load balancer with many extra “layer 7″ functions to route, filter, and cache traffic for web and application servers. It was built on a general-purpose Linux core, and is sold as a hardware appliance. Now it has been released as a virtual appliance. We’ve talked with our prospects here, and they are intrigued: they like the flexibility of starting off with a load balancer, and doing early application testing with one, and being able to smoothy upgrade to a dedicated hardware appliance as their load grows. Other companies whose products have similar values are the Open Source Router from Vyatta, Reflex VSA for intrusion detection, LoadBalancer.org, and Proofpoint’s email filter. (If you know others, please feel free to submit the name and link in the comments to this post.)

None of these will run as fast in a vm as they will in an engineered hardware appliance, where they could conceivably achieve wire speed of 100 mbps or even 1 gbps, instead of a vm’s more typical 25-50 mbps. But then again, it’s rare that most applications ever see that much demand for their services — under 20 mbps is more typical. In fact, there are cases where the traffic from many applications are forced through a single hardware appliance “because it’s there,” when a more logical network topology would separate the traffic and give each application its own appliance. For example, firewalls sometimes have extremely complex configurations because they manage security for many different applications in a single box, when they could be more easily managed with one firewall per application. Disaggregate the traffic and you may reduce complexity and configuration errors, while lowering the traffic rates to levels more suitable for a virtual appliance. As cores become more numerous in servers, it may become more appealing to use them for network functions, replacing hardware and cabling with software.

I’ve seen some data centers where the “network guys” and the “application guys” are different tribes and hardly understand each other. The network guys generally buy and wire up boxes, while the application guys mostly buy and configure software. It’s a little like the old days, with telephone and PBX guys separated from the computer guys (though not as bad, thankfully). The new options for network functions in virtual appliances could cause another wave of convergence, both in the equipment and the staffing in the data center.

Entry Filed under: Networking, Software appliances