Analysis: The Virtual Data Center

IP networks achieved dominance because they're dumb. No central brain--positronic or otherwise--means resilience. But now Cisco Systems, Juniper Networks, Microsoft, and a host of startups are meddling with nature by selling programmable platforms that can understand and process the data running over them, moving smarts back from servers and other endpoints. This raises the specter of higher hardware costs, as proprietary switches replace commodity devices. So, do the benefits of a smarter--and presumably more flexible and faster--network balance the risk of lock-in?

Cisco has set its sights first on shattering servers into pools of resources, like CPUs and memory, that are networked. It envisages a future in which the enterprise data center is reduced to little more than a virtual machine running on a giant switch--which, of course, it will provide. Juniper is giving its switches an API that third-party applications can access. 3Com is partnering with VMware to put virtual servers inside routers, and startups are scheming to steal the smarts from a huge variety of endpoints, from radio frequency identification readers to wireless sensors. Even IBM is joining the trend, selling appliances that off-load XML processing from servers and accelerate its WebSphere middleware using dedicated silicon.

THINKING INSIDE THE BOX
Part of what seems like network overreach is the usual progress of technology. Just as cell phones absorbed cameras and music players, network switches added firewall, Wi-Fi radio management, and network access control. These combined devices can be shipped preconfigured, a boon for remote offices that lack IT staff. Not surprisingly, then, branch office hardware is an obvious place for networking vendors to start co-opting functions. In addition to the usual security features, Nortel Networks' Secure Router can run voice-over-IP and collaboration software from partner Microsoft, while Cisco's Integrated Service Router, or ISR, may include modules for XML acceleration or WAN optimization.

CIOs of distributed organizations are taking notice."We like that it's plug and play," says Armin Heinlein, corporate VP and head of IT at shipping conglomerate Panalpina Group, which has installed the Cisco ISR with a WAN optimization module at 23 branch offices. "It consolidates everything into one device and helped us get rid of remote file servers."

But Cisco's angling for bigger fish than the branch office. Its top priority after making one of its many acquisitions is usually to convert the company's technology into a module for the Catalyst 6500, its giant data center switch. Not all of these buys are obvious network services, but Cisco argues that there's little difference between a network service, such as a firewall, and an application, such as a database.

"Most network services started as applications," says Bill Ruh, VP of advanced services at Cisco. "Things have been migrating into the network for the last 10 years." In particular, network devices are good at functions that benefit from specialized silicon: An individual server might not use SSL or XML enough to justify an internal accelerator card, but an appliance can be shared. Moving functions away from servers also saves on software licensing costs, as more of the server's power can be dedicated to running a licensed app.

(click image for larger view)

FROM PIPE TO PIPE DREAM
It's easy to see why replacing servers with network devices appeals to Cisco, but what's in it for us? Right now, most servers run on commodity x86 boxes. Moving functionality to switches entails proprietary hardware, locking customers into one vendor's platform--often at a premium price. Why make the move?

Two reasons, according to Cisco. First, a lot more bandwidth. Applications running on a switch have direct access to the device's full backplane capacity--256 Gbps in the case of the Catalyst 6500, 15 Tbps for the Nexus 7000, the next-gen switch that Cisco launched last month. Second, much greater flexibility. In his keynote at Cisco's annual C-Scape conference, CEO John Chambers talked of VMs that travel around the world to run wherever power costs are lowest, perhaps sitting next to a nuclear power plant at times of low power demand or simply chasing the sun.Few applications really need a direct connection to a switch backplane, something Cisco tacitly admits in its own product line. The company hasn't yet ported some less network-centric products, such as its Call Manager PBX software or Wireless Location Appliance, to the 6500. IP telephony and queries on Wi-Fi users' whereabouts run happily over standard Ethernet, so plugging them directly into the switch would waste a Catalyst slot.

This equation should change as virtualization goes mainstream. While a single application or appliance may not need enough bandwidth to justify a switch slot, multiple applications or virtual appliances aggregated together are another matter. While a traditional architecture might use a 16-port Gigabit Ethernet module to connect one switch to 16 servers, the virtual data center would put 16 virtual machines right on the module. These VMs will have little relation to what we now think of as servers. For maximum flexibility, workloads must be able to move among servers--or switches--without necessarily dragging data with them, so they won't contain hard disks, relying instead on storage area networks. Cisco thinks the same will happen to memory: It will migrate outside the server or VM, requiring a new type of network to link memory and CPU.

The network really will become the computer.

How realistic is this vision? Cisco hasn't yet released a module for the Cat 6500, or any other switch, that can run third-party applications, and it won't say when (or if) it will. However, it describes the vision as spanning 10 years; there are still technical and physical barriers to overcome. Running applications at switch backplane speed will generate a lot of heat, which, according to Cisco, is one reason it won't initially release Catalyst-style service modules for the faster Nexus. The new switch is aimed only at network aggregation, virtualizing SANs and LANs over the same physical cable.

(click image for complete view of chart)CHOICES BEYOND CISCO

Competing vendors are grabbing onto this trend. In January 2007, 3Com launched its Open Services Network product line, aimed at moving server functions to networking devices. The most important is the OSN Module, a blade server that plugs in to its 6000 series enterprise routers and multiservice routers, or MSRs, for branch offices. Running a customized version of Linux, the blade has a direct connection to the router's backplane and a link to its control channel via a 3Com API. This lets applications on the blade route traffic to a particular destination, prioritize some packets over others, or select some for deeper processing.So far, OSN works only with routers, not switches, so it doesn't come with the bandwidth benefits that Cisco envisages, though 3Com, too, says it plans to use the technology for switches. The main OSN selling point is the same as that of other integrated appliances: tight integration of code with the network infrastructure, making it particularly suitable for applications related to networking.

OSN ought to be more open than competitors' approaches, as it can run any Linux application. However, access to the router's internals is so far limited to software from 3Com and its partners. For now, 3Com ships customized versions of several open source apps, including the Wireshark protocol analyzer, NTOP traffic probe, and Nagios monitoring software. Partner applications announced so far include WAN optimization from Expand Networks, IP telephony from Digium, e-mail leak prevention from Vericept, and security event management from Q1 Labs.

Expand's participation looks anomalous, as it usually sells hardware, not software. But like most WAN optimization vendors, it's really a software company, selling appliances preconfigured as blade servers. "We want to give customers a choice of platforms," says Dave White, Expand's VP of business development. Combining WAN optimization with a router makes sense because both have settings that affect traffic prioritization.

For now, 3Com is partnering with VMware so that OSN routers can run Windows and any other x86 operating system. But like Linux apps that haven't been rewritten, they won't have access to the router's inner workings. 3Com says it plans to ship a software development kit for third-party developers within the first half of this year to let companies port in-house apps to the platform.

Some customers are already there. Everus Communications, a wireless ISP in rural Ontario, is moving a homegrown management app to the MSR, says John Tinholt, director of IP networking. Tinholt is placing MSRs at most of the provider's 62 Wi-Fi points of presence, where they function mainly as access routers. The management app, which now runs on Linux servers, collects data from customer premises equipment and alerts support personnel when it detects a problem.But the porting process isn't finished, and Everus doesn't know how long it will take. For now, routers are running only 3Com's own open source applications, though, according to Tinholt, this is still valuable. "The OSN module definitely weighed on our decision to use the MSR," he says, adding that price was also a factor in choosing the 3Com box over Cisco's ISR. "Being able to use familiar Linux apps is important."OPENING THE PACKET
An open API on a switch or router can be useful even if applications are running on servers elsewhere. This is the thinking behind Cisco's and Juniper's plans to open their IOS and JunOS platforms. When Cisco and Juniper talk about being open, they don't mean their code will be open source like Linux, or even able to run on standard hardware, as Windows does. Rather, third-party apps will be able to control most of the switch's or router's functions through an API. For example, a video server could ensure that some types of video are given priority, while a security app might block or throttle particular traffic types. Most of this functionality is already available, but usually only through the vendor's proprietary system. An API ought to give customers more choice, improving integration with third-party apps.

Of the two vendors' plans, Juniper's are furthest along: It already has created a software development kit and signed several members to its Partner Solution Development Program, including Aricent and Avaya. Most are developing for Juniper's traditional service provider market, but Juniper also thinks third parties will develop JunOS apps for the enterprise switches it launched last month. Few enterprise users will build their own apps, however. Though the program is described as open, members pay an annual licensing fee for access to the API and SDK.

The only truly open router vendor is Vyatta, whose open source routing platform runs on standard x86 hardware. That means it can integrate with just about anything, but you're limited on performance of commodity hardware. This vision is the opposite of Cisco's: Rather than virtualizing servers in switches, Vyatta is betting that increases in computing power will make blade servers a viable alternative to routers.

The first company to partially open its switching API was Extreme Networks, which in May 2005 announced that partners would be able to control XOS, the operating system that powers its high-end BlackDiamond switches. However, it so far has signed up only four partners: Avaya and security vendors CipherOptics, StillSecure, and ISS (since acquired by IBM). As with the Juniper architecture, apps don't actually run on a switch. Instead, they're represented by a switch-side agent that reports back to a separate server or appliance. Extreme says it won't open the API to customers or third parties, as this could destabilize the network.

Juniper denies destabilization is a problem with open JunOS. "People buy us for high performance, and we can't compromise that," says Kathy Gadecki, the development program manager at Juniper. User-developed code runs in a separate VM, isolated from the main operating system so bugs won't crash the switch. Of course, a badly written app could still cause problems, so thorough testing is essential.BABY STEPS
If shifting applications wholesale to a switch sounds too radical, how about just moving certain functions? This is essentially what application front ends and XML accelerators already do, but several vendors want to take that concept much further. The principle is that service-oriented architectures break applications into smaller components, which can then be spread around to whichever hardware is most appropriate.Cisco's Ruh says some pieces of an application may belong in a router or a switch. For example, application firewalls already perform deep-packet inspection to scan for threats. That means they're in a good position to also process traffic based on its contents. Cisco's been pushing this idea since it launched Application-Oriented Networking, or AON, a suite of XML hardware available as a standalone appliance or as a module for the ISR and Catalyst 6500. AON can't run full applications in the way 3Com's OSN modules do, but it's more flexible than standard XML accelerators. Though based on similar hardware, it's programmable to support non-XML messaging protocols and custom data formats.Problem is, AON hasn't proved popular--Cisco was unable to put us in touch with anyone actually using the products. In an apparent admission of defeat, a year ago the company acquired Reactivity, a maker of a more typical XML appliance that Cisco now sells as the ACE XML Gateway. Like competing products from IBM and Layer 7, ACE can implement common Web services operations like encrypting XML elements and verifying SAML assertions while it's inspecting packets, but it doesn't try to be as customizable as AON. Still, Cisco says it hasn't abandoned AON and believes there eventually will be a place for programmable XML processors at the network core.

OVER THE EDGEAt least three startups are also chasing the idea of non-XML application network appliances, though they're not aimed at the data center. Augusta Systems, Blue Vector Systems, and Omnitrol focus on processing data gathered from what they call "edge assets." Those include RFID readers and other sensors that are just now being linked into enterprise IT systems. The appliances aim to handle data from these assets locally, without involving a data center or a server.

"The network management issues that arise from the deluge of edge asset data require an intelligent network infrastructure," says Patrick Esposito, Augusta's president and chief operating officer. Such assets tend to be located in warehouses, factories, and other areas far from corporate data centers, giving this kind of appliance the same business case as WAN optimization--to avoid sending data over costly, slow WAN links.

Augusta started as a software company, selling .Net-based middleware called EdgeFrontier. Though most customers still install EdgeFrontier on Windows servers, Augusta expects to move into switches and routers; it's talking with at least two potential partners.

Omnitrol and Blue Vector also make appliances, again designed to be installed at remote locations. Omnitrol's includes a wireless switch that works with access points from 3Com and D-Link, aiming to take care of all of a branch office's communications needs. Blue Vector is more tightly focused on RFID, often combining its products with RFID readers. For example, it has an RFID-equipped refrigerator aimed at the pharmaceutical industry that automatically reorders drugs when supplies get low. It has also partnered with Nortel to use wireless mesh networks to link sensors.Allegheny Power is using the Augusta boxes to build what it calls a self-healing electric grid. The SensorPorts process measurements from voltage sensors on power lines, temperature sensors in transformers, and moisture sensors in areas prone to flooding, rerouting power in case of an outage. "It's a way to transfer loads back and forth without having to rebuild our entire utility system," says Harley Mayfield, a planning engineer at Allegheny.

Sending meter readings all the way to a data center is not an option because the network is often out along with the power. The project is still just a pilot using a single SensorPort, but Allegheny plans to install 12 SensorPorts at substations, linked wirelessly to about 1,000 sensors throughout the grid. It also hopes to use the same infrastructure for automated meter readings for 1.5 million customers in Maryland and surrounding states.

Mayfield likes the way the appliance supports almost every type of sensor. "It's like tying a thermostat to a game console to a VCR," he says. "Being an old Star Trek fan, I look at the SensorPort as a universal translator." But as with the 3Com box, actually programming it isn't easy. He's had to bring in an outside company to provide custom software.

Still, that's an improvement over how sensor networks used to work. Developers working on sensor networks are used to debugging with an oscilloscope, says Joe Polastre, CTO of sensor software startup Sentilla. The company has ported a Java runtime to the 8-bit processors used in wireless motes, the dime-size nodes that make up wireless sensor networks, and sells an Eclipse-based SDK that lets developers cut and paste code directly from the Java apps used in most SOAs. Sentilla has signed up customers in the agricultural and border-security sectors. The business case is the same as with appliances and WAN optimizers writ small: to save bandwidth.

"The more processing you do on the sensor, the less you need a network at all," Polastre says. And with a tiny battery-powered device that consumes energy every time it transmits, avoiding the network means big savings in maintenance.Sentilla and similar companies like Arch Rock could be the Achilles' heel of the movement toward intelligent networks. Once applications bust out of the data center, why should they stay in the network? Why not migrate all the way to endpoints, leaving the network as, again, just a pipe? Something to consider when deciding whether to buy into this new network vision.