Daily Archives: March 6, 2012

Why Many Networking Professionals Will Resist Software-Defined Networking

In the long run, I think software defined networking (SDN) is destined for tremendous success, not only at massive cloud service providers, where it already is finding favor and increased adoption, but also at smaller service providers and even — with time and perseverance — at enterprises.

It just might not happen as quickly as some expect.

Shape of Networking to Come

In a presentation last autumn at the Open Networking Summit, Nicira co-founder Nick McKeown asserted that SDN would shape the future of networking in several key respects. He said it would do so by empowering network owners and operators, by speeding the pace of innovation, by diversifying the supply chain, and by delivering a robust foundation for programmability predicated on a standardized forwarding abstraction and provable network properties.

On the whole, McKeown probably will be right, and his technological reasoning seems entirely reasonable. As in any market, however, the commercial appeal of SDN will be determined by human factors as well as by technological considerations.

The enterprise market will be the toughest nut to crack, though, and not only because the early agenda of SDN, as defined by the board members of the Open Networking Foundation (ONF) and others, has been focused resolutely on providing solutions for the largest of cloud service providers.

Winning Hearts and Minds

Capturing enterprise hearts and minds will be difficult for SDN, and it will be hard not just because of technological challenges, such as backward compatibility with (and investments in) existing network infrastructure, but also because of the cultural milieu and entrenched mindset of enterprise networking professionals.

I’ve written before, on two occasions actually, about how human and institutional resistance to change can strongly inhibit the commercial adoption of technologies with otherwise compelling credentials and qualifications. Generally, people fear change, especially when they suspect that the change in question will affect them adversely.

And make no mistake, software-defined networking will inspire fear and resistance in some quarters, enterprise networking professionals prominent among them.

Networking’s Cultural Artifacts

Jennifer Rexford, professor of computer science at Princeton University and a former AT&T Research staffer, wrote that one of her colleagues once observed that computer-networking people “really loved their artifacts.” Those artifacts probably would include the many distributed routing protocols that have proliferated over the years.

Software-defined networking wants to loosen emotional attachment to those artifacts, just as it wants to jettison the burgeoning bag of protocols that distinguishes networking from computer programming and other disciplines.  But many networking professionals, including those in enterprise IT departments, see their mastery of complex protocols as hallmarks of who they are and what they do.

Getting the Network “Out of the Way”

Yet there’s more to it than that. Consider the workplace implications of software-defined networks. The whole idea of SDN is to make networks programmable, to put applications and those who program and manage them in the driver’s seat, and to get the network “out of the way” of the sweeping virtualized progress that has enveloped all other data-center infrastructure.

To survive and thrive in this brave new virtual world, networking professionals might have to become more like programmers. From an organizational standpoint, even though there are compelling business and technological reasons to adopt SDN, resistance from the fraternity of networking professionals will be stiff and difficult to overcome.

In the realm of the super-sized data centers at Google and elsewhere, this isn’t a serious problem. The concepts associated with “DevOps” and with thinking outside boxes, departmental and otherwise, thrive in those precincts. Google long has eschewed the purchase of servers and networking gear from vendors, and it does things its own way. To greater or lesser degrees, other large cloud-service providers now dance to a similar beat. But the enterprise? Well, that’s a different animal altogether.

Vendors in No Hurry

Some of the new SDN startups already are meeting with pockets of resistance. They’re seeing cleavage — schism might be too strong a word, though maybe not — between cloud architects and server-virtualization specialists on one side of the house and network professionals on the opposing side. The two camps see things differently,with perspectives and priorities that are difficult to reconcile. (There are exceptions to the rule, of course, with some networking professionals eager to embrace SDN, but they currently are in the minority.)

As we’ve seen, the board of directors at the Open Networking Foundation (ONF) isn’t concerned about how quickly the enterprise gets with the SDN program. I also would suggest that most networking vendors, which are excluded from the ONF’s board, aren’t in a hurry to push an SDN agenda that features logically centralized, server-based controllers. You’ll see SDN from these vendors, yes, but the control plane will be distributed until such time as enterprises and service providers (not on the ONF board) demand otherwise. That will be a while, I suspect.

Deferred Gratification

We tend to underestimate resistance to change in this industry.  Gartner devised the “trough of disillusionment”  and the technology hype cycle for good reason. Some technologies remain in that basin longer than others. Some never emerge from what becomes a bottomless pit rather than a trough.

That won’t happen to SDN.  As I wrote earlier, I think it has a bright future. Don’t be surprised, though, if the hype gets ahead of the reality. When it comes to technologies and markets, our inherent optimism occasionally is thwarted by our intrinsic resistance to change.

Advertisements

Xsigo’s Virtualized Infrastructure Draws Cisco’s Fire

Long involved in the discussion about and the market for converged I/O, Xsigo wants to be part of a larger debate and a potentially much bigger market opportunity.

Xsigo said last summer that its goal was to virtualize components of data-center networking, just as servers and storage have been virtualized previously. Wait, some of you might say, isn’t that the purview of software-defined networking (SDN) vendors? Well, yes, that’s true, and while there are obvious differences between what Xsigo delivers and what’s being put on the table by SDN purveyors, Xsigo thinks it has a compelling story to tell.

Xsigo’s I/O Director started off addressing virtualization and data transfer between servers and storage. Last summer, though, its I/O Director stepped up to the server-to-server challenge, simultaneously extending its incursion onto server turf while making a claim on networking territory.

Cisco Takes Notice

That got the attention of Cisco Systems, which offers networking and servers, and a relatively vehement vendetta ensued between the two companies. Xsigo probably got more benefit than Cisco did from the mutual antagonism, if only because Cisco’s public reaction to Xsigo indicated that the smaller player had done enough damage to be considered a threat by the networking giant. In aiming its competitive marketing guns at Xsigo and blasting away, Cisco explicitly acknowledged Xsigo and implicitly conferred added legitimacy in the process.

At any rate, with the addition of the Xsigo Server Fabric, which began shipping in earnest toward the end of last year, the Xsigo I/O Director now allows servers and devices to connect to each other directly without going over the network. As a result, adding a virtual machine (VM) doesn’t involve using an IP address or setting up a virtual LAN (VLAN).  That’s addressed by I/O director and its virtual server interfaces.

Market analyst Zeus Kerravla has said that the Xsigo Server Fabric creates a new infrastructure atop the physical network, which is true enough. The Xsigo Server Fabric obviates the access-layer network, allowing servers and their VMs to communicate directly.

Bumping Layers

Xsigo contends its Server Fabric also effectively eliminates the aggregation layer. Xsigo says its infrastructure extends as for as the core network, where it is compatible with switches from any of the major players, including Cisco and Juniper. As such, Xsigo says its technology transforms a hierarchical network into a pool of bandwidth that can be used to connect virtualized resources in a data center.

By reducing the numbers of switch ports and infrastructure layers — the company says there’s just one layer of connectivity management between the OS or hypervisor and the core network with its approach as compared to as many as four layers in the Cisco model — Xsigo says its business model is the exact opposite of Cisco’s. Further to that point, Xsigo says that it is open, acting as a transparent conduit moving data between servers and the network core, whereas it alleges Cisco is not. Finally, Xsigo says it has no server agenda, whereas Cisco pushes its own servers as part of its Unified Computing System (UCS) for data-center virtualization.

Playing Its Part

Having no server agenda and taking a cut of the networking pie seem to have resulted in a go-it-alone strategy for Xsigo. It’s conceivable that market dynamics  and shifting vendor alliances could change that picture, but for now Xsigo doesn’t have a powerful technology-partner ecosystem to leverage.  As The Register noted, Xsigo has no OEM deals and is not thought to be an acquisition target of a major player, though Dell is responsible for about 20 percent of Xsigo’s sales and Oracle is cited as a potential acquirer in some quarters.

Xsigo customers, including some big names, have derived some significant cost savings from cutting down on cabling and getting much greater utilization from servers, virtual machines, and their network resources.

While not a member of the SDN fraternity, Xsigo wants us to know that it is playing its part in virtualized infrastructure for the data center.