Between What Is and What Will Be

I have refrained from writing about recent developments in software-defined networking (SDN) and in the larger realm of what VMware, now hosting VMworld in San Francisco, calls the  “software-defined data center” (SDDC).

My reticence hasn’t resulted from indifference or from hype fatigue — in fact, these technologies do not possess the jaundiced connotations of “hype” — but from a realization that we’ve entered a period of confusion, deception, misdirection, and murk.  Amidst the tumult, my single, independent voice — though resplendent in its dulcet tones — would be overwhelmed or forgotten.

Choppy Transition

We’re in the midst of a choppy transitional period. Where we’ve been is behind us, where we’re going is ahead of us, and where we find ourselves today is between the two. So-called legacy vendors, in both networking and compute hardware, are trying to slow progress toward the future, which will involve the primacy of software and services and related business models. There will be virtualized infrastructure, but not necessarily converged infrastructure, which is predicated on the development and sale of proprietary hardware by a single vendor or by an exclusive club of vendors.

Obviously, there still will be hardware. You can’t run software without server hardware, and you can’t run a network without physical infrastructure. But the purpose and role of that hardware will change. The closed box will be replaced by an open one, not because of any idealism or panglossian optimism, but because of economic, operational, and technological imperatives that first are remaking the largest of public-cloud data centers and soon will stretch into private clouds at large enterprises.

No Wishful Thinking

After all, the driving purpose of the Open Networking Foundation (ONF) involved shifting the balance of power into the hands of customers, who had their own business and operational priorities to address. Where legacy networking failed them, SDN provided a way forward, saving money on capital expenditures and operational costs while also providing flexibility and responsiveness to changing business and technology requirements.

The same is true for the software-defined data center, where SDN will play a role in creating a fluid pool of virtualized infrastructure that can be utilized to optimal business benefit. What’s important to note is that this development will not be restricted to the public cloud-service providers, including all the big names at the top of the ONF power structure. VMware, which coined software-defined data center, is aiming directly for the private cloud, as Greg Ferro mentioned in his analysis of VMware’s acquisition of Nicira Networks.

Fighting Inevitability

Still, it hasn’t happened yet, even though it will happen. Senior staff and executives at the incumbent vendors know what’s happening, they know that they’re fighting against an inevitability, but fight it they must. Their organizations aren’t built to go with this flow, so they will resist it.

That’s where we find ourselves. The signal-to-noise ratio isn’t great. It’s a time marked by disruption and turmoil. The dust and smoke will clear, though. We can see which way the wind is blowing.

Advertisement

Some Thoughts on VMware’s Strategic Acquisition of Nicira

If you were a regular or occasional reader of Nicira Networks CTO Martin Casado’s blog, Network Heresy, you’ll know that his penultimate post dealt with network virtualization, a topic of obvious interest to him and his company. He had written about network virtualization many times, and though Casado would not describe the posts as such, they must have looked like compelling sales pitches to the strategic thinkers at VMware.

Yesterday, as probably everyone reading this post knows, VMware announced its acquisition of Nicira for $1.26 billion. VMware will pay $1.05 billion in cash and $210 million in unvested equity awards.  The ubiquitous Frank Quattrone and his Quatalyst Partners, which reportedly had been hired previously to shop Brocade Communications, served as Nicira’s adviser.

Strategic Buy

VMware should have surprised no one when it emphasized that its acquisition of Nicira was a strategic move, likely to pay off in years to come, rather than one that will produce appreciable near-term revenue. As Reuters and the New York Times noted, VMware’s buy price for Nicira was 25 times the amount ($50 million) invested in the company by its financial backers, which include venture-capital firms Andreessen Horowitz, Lightspeed,and NEA. Diane Greene, co-founder and former CEO of VMware — replaced four years ago by Paul Maritz — had an “angel” stake in Nicira, as did as Andy Rachleff, a former general partner at Benchmark Capital.

Despite its acquisition of Nicira, VMware says it’s not “at war” with Cisco. Technically, that’s correct. VMware and its parent company, EMC, will continue to do business with Cisco as they add meat to the bones of their data-center virtualization strategy. But the die was cast, and  Cisco should have known it. There were intimations previously that the relationship between Cisco and EMC had been infected by mutual suspicion, and VMware’s acquisition of Nicira adds to the fear and loathing. Will Cisco, as rumored, move into storage? How will Insieme, helmed by Cisco’s aging switching gods, deliver a rebuttal to VMware’s networking aspirations? It won’t be too long before the answers trickle out.

Still, for now, Cisco, EMC, and VMware will protest that it’s business as usual. In some ways, that will be true, but it will also be a type of strategic misdirection. The relationship between EMC and Cisco will not be the same as it was before yesterday’s news hit the wires. When these partners get together for meetings, candor could be conspicuous by its absence.

Acquisitive Roads Not Traveled

Some have posited that Cisco might have acquired Nicira if VMware had not beaten it to the punch. I don’t know about that. Perhaps Cisco might have bought Nicira if the asking price were low, enabling Cisco to effectively kill the startup and be done with it. But Cisco would not have paid $1.26 billion for a company whose approach to networking directly contradicts Cisco’s hardware-based business model and market dominance. One typically doesn’t pay that much to spike a company, though I suppose if the prospective buyer were concerned enough about a strategic technology shift and a major market inflection, it might do so. In this case, though, I suspect Cisco was blindsided by VMware. It just didn’t see this coming — at least not now, not at such an early state of Nicira’s development.

Similarly, I didn’t see Microsoft or Citrix as buyers of Nicira. Microsoft is distracted by its cloud-service provider aspirations, and the $1.26 billion would have been too rich for Citrix.

IBM’s Moves and Cisco’s Overseas Cash Horde

One company I had envisioned as a potential (though less likely) acquirer of Nicira was IBM, which already has a vSwitch. IBM might now settle for the SDN-controller technology available from Big Switch Networks. The two have been working together on IBM’s Open Data Center Interoperable Network (ODIN), and Big Switch’s technology fits well with IBM’s PureSystems and its top-down model of having application workloads command and control  virtualized infrastructure. As the second network-virtualization domino to fall, Big Switch likely will go for a lower price than did Nicira.

On Twitter, Dell’s Brad Hedlund asked whether Cisco would use its vast cash horde to strike back with a bold acquisition of its own. Cisco has two problems here. First, I don’t see an acquisition that would effectively blunt VMware’s move. Second, about 90 percent of Cisco’s cash (more than $42 billion) is offshore, and CEO John Chambers doesn’t want to take a tax hit on its repatriation. He had been hoping for a “tax holiday” from the U.S. government, but that’s not going to happen in the middle of an election campaign, during a macroeconomic slump in which plenty of working Americans are struggling to make ends meet. That means a significant U.S.-based acquisition likely is off the table, unless the target company is very small or is willing to take Cisco stock instead of cash.

Cisco’s Innovator’s Dilemma

Oh, and there’s a third problem for Cisco, mentioned earlier in this prolix post. Cisco doesn’t want to embrace this SDN stuff. Cisco would rather resist it. The Cisco ONE announcement really was about Cisco’s take on network programmability, not about SDN-type virtualization in which overlay networks run atop an underyling physical network.

Cisco is caught in a classic innovator’s dilemma, held captive by the success it has enjoyed selling prodigious amounts of networking gear to its customers, and I don’t think it can extricate itself. It’s built a huge and massively successful business selling a hardware-based value proposition predicated on switches and routers. It has software, but it’s not really a software company.

For Cisco, the customer value, the proprietary hooks, are in its boxes. Its whole business model — which, again, has been tremendously successful — is based around that premise. The entire company is based around that business model.  Cisco eventually will have to reinvent itself, like IBM did after it failed to adapt to client-server computing, but the day of reckoning hasn’t arrived.

On the Defensive

Expect Cisco to continue to talk about the northbound interface (which can provide intelligence from the switch) and about network programmability, but don’t expect networking’s big leopard to change its spots. Cisco will try to portray the situation differently, but it’s defending rather than attacking, trying to hold off the software-based marauders of infrastructure virtualization as long as possible. The doomsday clock on when they’ll arrive in Cisco data centers just moved up a few ticks with VMware’s acquisition of Nicira.

What about the other networking players? Sadly, HP hasn’t figured out what to about SDN, even though OpenFlow is available on its former ProCurve switches. HP has a toe dipped in the SDN pool, but it doesn’t seeming willing to take the initiative. Juniper, which previously displayed ingenuity in bringing forward QFabric, is scrambling for an answer. Brocade is pragmatically embracing hybrid control planes to maintain account presence and margins in the near- to intermediate-term.

Arista Networks, for its part, might be better positioned to compete on networking’s new playing field. Arista Networks’ CEO Jayshree Ullal had the following to say about yesterday’s news:

“It’s exciting to see the return of innovative networking companies and the appreciation for great talent/technology. Software Defined Networking (SDN) is indeed disrupting legacy vendors. As a key partner of VMware and co-innovator in VXLANs, we welcome the interoperability of Nicira and VMWare controllers with Arista EOS.”

Arista’s Options

What’s interesting here is that Arista, which invariably presents its Extensible OS (EOS) as “controller friendly,” earlier this year demonstrated interoperability with controllers from VMware, Big Switch Networks, and Nebula, which has built a cloud controller for OpenStack.

One of Nebula’s investors is Andy Bechtolsheim, whom knowledgeable observers will recognize as the chief development officer (CDO) of, and major investor in, Arista Networks.  It is possible that Bechtolsheim sees a potential fit between the two companies — one building a cloud controller and one delivering cloud networking. To add fuel to this particular fire, which may or may not emit smoke, note that the Nebula cloud controller already features Arista technology, and that Nebula is hiring a senior network engineer, who ideally would have “experience with cloud infrastructure (OpenStack, AWS, etc. . . .  and familiarity with OpenFlow and Open vSwitch.”

 Open or Closed?

Speaking of Open vSwitch, Matt Palmer at SDN Centralwill feel some vindication now that VMware has purchased a company whose engineering team has made significant contributions to the OVS code. Palmer doubtless will cast a wary eye on VMware’s intentions toward OVS, but both Steve Herrod, VMware’s CTO, and Martin Casado, Nicira’s CTO, have provided written assurances that their companies, now combining, will not retreat from commitments to OVS and to Open Flow and Quantum, the OpenStack networking  project.

Meanwhile, GigaOm’s Derrick Harris thinks it would be bad business for VMware to jilt the open-source community, particularly in relation to hypervisors, which “have to be treated as the workers that merely carry out the management layer’s commands. If all they’re there to do is create virtual machines that are part of a resource pool, the hypervisor shouldn’t really matter.”

This seems about right. In this brave new world of virtualized infrastructure, the ultimate value will reside in an intelligent management layer.

PS: I wrote this post under a slight fever and a throbbing headache, so I would not be surprised to discover belatedly that it contains at least a couple typographical errors. Please accept my apologies in advance.

Infrastructure Virtualization Versus Converged Infrastructure

While writing about software-defined networking (SDN) and what it makes possible, I have been thinking about how its essential premise, and the premise behind infrastructure virtualization, conflicts with visions of converged infrastructure promulgated by the leading systems vendors in the information-technology (IT) industry.

According to the Wikipedia definition, converged infrastructure encompasses servers, storage, networking gear, and software for IT infrastructure management, automation, and orchestration. Accordingly, converged infrastructure leverages pooled IT resources to facilitate automated resource provisioning in support of dynamic application workloads.

Hardware Pedigrees in Software World

Leading vendors, most with more hardware than software pedigrees, have sought to offer proprietary converged-infrastructure offerings that closely integrate the hardware elements with software-based management attributes. In this regard,  we can cite vendors such as Cisco (with a storage assist from EMC or NetApp), Hewlett-Packard, Dell, Hitachi Data Systems, Oracle (though networking remains on open question there),  and, perhaps to a lesser extent, IBM.

Now, let’s think about SDN and where it ultimately leads. Cisco would like us to believe that SDN, if it leads anywhere, will eventually take us to network programmability, with a heavy emphasis on the significance of a northbound API (or APIs).  Cisco says that the means — in this case, SDN — are not as important as the desired ends, networking programmability, and many of Cisco’s enterprise customers will doubtless agree.

SDN End Games

Another SDN outcome is network virtualization, which admittedly can also be achieved through other means. But an interesting aspect of SDN’s approach to network virtualization, with its decoupling of the network’s control and data planes, is that it results in the abstracting of software-based network intelligence from the underlying hardware-based network brawn. It’s a software paradigm taken to a logical extreme, with server-based software running at the network edge controlling an abstracted pool of no-frills networking hardware.

Indeed, this is one end game for SDN, first playing out in the data centers of the major cloud service providers that guide the affairs of the Open Networking Foundation (ONF), and then — at some indeterminate future point too difficult to forecast without a Ouija board and a bottle of scotch  — also at large enterprises worldwide.

Let’s elaborate further. SDN facilitates network virtualization, which in turn is harnessed and orchestrated by cloud-management software, which also manages virtualized compute and storage infrastructure. As we’ve seen already in the compute world of servers, it’s getting increasingly difficult for a vanity hardware vendor to earn a buck in a virtualized world. Many service providers have found that they can get boxes that satisfy their needs, at lower prices, directly from ODMs that often build servers for name-brand OEMs.  Storage is being virtualized, too.

Network’s Turn

And now it is the network’s turn.

In such a world, how much longer will it make sense for customers to achieve converged infrastructure from single-source vendors that equip their hardware with proprietary fripperies and hooks to facilitate lock-in? Again, we can see these trend playing out at large service providers. Some have begun buying their networking hardware off the rack from ODMs, saving not only on capital expenditures (certainly the case for servers), but also on operating expenses relating to the ongoing management of network infrastructure. It’s true that they’re trading one sort of complexity for another, pushing it up the stack and into software rather than an operational hardware, but it’s a trade-off they’re clearly willing to make, probably because they have the resources and skill sets to make it work (and pay).

Obviously that is not a recipe for everybody, certainly not for most enterprises today. But times are changing, and it isn’t inconceivable to foresee a day when the enterprise will be able to avail itself of third-party private-cloud software and management tools that will allow it to exploit a similar model of virtualized infrastructure.

Prescience Pays Off

In the big picture, as far as the established networking vendors are concerned, the ONF’s conception of SDN is about more than just OpenFlow, and even about more than network programmability. It’s about how SDN supports a model of network virtualization, in service to infrastructure virtualization, that significantly enfeebles hardware-based business models. Some of these hardware-oriented vendors will not successfully pivot to a model of virtualized infrastructure and software primacy.

On the other hand, some vendors have had the prescience to see this trend approaching on the horizon; they understand its inevitability, and they have positioned themselves better than others to survive, and perhaps even thrive, after the eventual market transition.

We’ll look at one of those vendors in a subsequent post.

Addressing SDN Burnout

In the universe of staccato text bursts that is Twitter, I have diagnosed a recent exhaustion of interest in software defined networking (SDN).

To a certain degree, the burnout is understandable. It is a relatively nascent space, generating more in the way of passionate sound and fury than in commercial substance. Some Twitter denizens with a networking bent have even questioned whether an SDN market — involving buyers as well as sellers — actually exists.

On that score, the pointed skepticism has been refuted. SDN vendors, including Nicira Networks and Big Switch Networks, increasingly are reporting sales and customer traction. What’s more, market-research firms have detected signs of commercial life. International Data Corporation (IDC), for example, has said the SDN market will be worth a modest $50 million this  year,  but that it will grow to $200 million in 2013 and to $2 billion by 2016. MarketsandMarkets estimates that the global SDN market will expand from $198 million in 2012 to $2.10 billion in 2017, representing a compound annual growth rate (CAGR) of 60.43% during that span.  I’m sure other market measurers will make their projections soon enough.

But just what are they counting? SDN isn’t a specific product category, like a switch; it’s an architectural model. In IDC’s case, the numbers include SDN-specific switching and routing as well as services and software (presumably including controllers and the applications that run on them). MarketsandMarkets is counting  SDN “switching, controllers, cloud virtualization applications, and network virtualization security solutions.”

Still, established networking vendors will argue that the SDN hype is out of proportion with on-the-ground reality. In that respect, they can cite recent numbers from Infonetics Research that estimate global revenue derived from sales of data-center network equipment — the market segment SDN is likely to make most headway during the next several years — was worth $2.2 billion in the first quarter of 2012. Those numbers include sales of Ethernet switches, application delivery controllers (ADCs), and WAN-optimization appliances.

This is where things get difficult and admittedly subjective. If we’re considering where the industry and customers stand today, then there’s no question that SDN gets more attention than it warrants. Most of us, including enterprise IT staff, do not wish to live in the past and don’t have the luxury of looking too far into the future.

That said, some people have the job of looking ahead and trying to figure out how the future will be different from the present. In the context of SDN, those constituencies would include the aforementioned market researchers as well as venture capitalists, strategic planners, and technology visionaries. I would also include in this class industry executives at established and emerging vendors, both those directly involved in networking technologies and those that interact with networking infrastructure in areas such as virtualization and data-center management and orchestration.

For these individuals, SDN is more than a sensationalized will-o’-the-wisp.  It’s coming. The only question is when, and getting that timing right will be tremendously important.

I suppose my point here is that some can afford to be dismissive of SDN, but others definitely cannot and should not. Is interest in SDN overdone? That’s subjective, and therefore it’s your call. I, for one, will continue to pay close attention to developments in a realm that is proving refreshingly dynamic, both technologically and as an emerging market.

In Assessing SDN’s Future, Take Care in Picking Precedents

Software-defined networking (SDN) continues to generate considerable attention and commentary, with this humble corner of the Internet contributing to the hubbub. There’s always a danger, especially with new technologies, that the hype cycle will result in a scenario in which proponents will overpromise and the technologies, understandably, will underdeliver.

When that happens, disappointment ensues. Gartner calls it the “trough of disillusionment,” which often serves as the darkness before the market dawn.

Certainly many caveats have been raised as expectation moderators to SDN. These caveats often come with references to preceding technologies that didn’t quite evolve according to originator intent or market plan. Lately, in fact, some have cited the slow adoption of IPv6 as a cautionary tale for SDN.

Not Analogous

In more than one respect, however, the comparison of IPv6 comparison with SDN doesn’t fly.

As the existence of the Open Networking Foundation (ONF) attests, large cloud service providers clearly perceive compelling business reasons  for the development and deployment of SDN solutions. Conversely, IPv6 was seen as something enterprises and service providers would have to do eventually as opposed to something they wanted to do.

Where the switch to IPv6 from IPv4 was driven by fear, the transition from conventional networking to software-defined networking (SDN), at least for large service providers, is being driven by the desire for business benefits and increased operational efficiency. While the purveyors of IPv6 sternly wielded a threatening stick to drive compliance, the champions of SDN at the ONF waved the carrots of network programmability and reduced operating expenditures. It was something they want, not something fear compels them to do.

Yes, I know that there always were good business reasons for enterprises and service providers to adopt IPv6, but those reasons often were articulated poorly or inadequately. Instead, fear took center stage, attempting to browbeat and threaten its audience into abject fealty.

Only Works for the Mob

Nobody likes to be threatened. Negative sales campaigns, predicated on implicit or explicit threats of impending doom, are less likely to resonate than those that are positive and inspiring. (Unless, of course, you’re running a protection racket for the mob, in which case your threats might be pretty damn effective, at least for a while.) IPv6 was all about the approach of darkening storm clouds, wheres SDN offers the promise of sunny innovation and a bright future.

As technologies and as market phenomena, IPv6 and SDN have little in common. It seems folly to cite the slow rate of adoption of IPv6 as a predictive precursor for SDN.

So, while SDN might not live up to its promise — and it will meet particularly strong headwinds in the enterprise — it will not face the same problems that confronted IPv6. They are qualitatively different technologies, and SDN will experience a market trajectory quite different from that of IPv6.

Why Established Networking Vendors Aren’t Leading SDN Charge

Expressing equal parts exasperation and incredulity, Greg Ferro wonders why industry-leading networking vendors aren’t taking the innovative initiative in offering compelling strategies for software-defined networking (SDN).

The answer seems clear enough.

Although applications will be critical to the long-term commercial success of SDN, Google and the other movers and shakers that direct the affairs of the Open Networking Foundation (ONF) originally were drawn to SDN because they were frustrated with the lack of responsiveness and innovation from established vendors. As a result, they devised a networking model that not only separated the control and data planes of network elements, but that also, in the word’s of Google’s Amin Vahdat, separated the “ evolution path for (network) hardware and software.”

Two Paths

Until now, those evolutionary paths have been converged and constrained inside the largely propriety boxes of networking vendors. Google and its confreres with the ONF perceived that state of affairs as the yoke of vendor oppression. The network, slow to evolve and innovate, was getting in the way of progress.  All the combustible ingredients of a cloud-service provider insurrection had cohered. Google, taking the lead in organizing the other major service providers under the rubric of the ONF, lit the fuse.

The effects of the explosion are just being felt, and the reverberations will echo for some time. The big service providers, and perhaps many smaller ones, are gravitating away from the orbit of networking’s ancien regime. The question now is whether enterprises will follow. At some point, that probably will happen, but how and when it will unfold are less clear. Enterprises, unlike the board members of the ONF, are too diverse and prolific to organize in pursuit of common interests. Accordingly, vendors are still able to set the enterprise agenda.

But enterprises will notice the benefits that SDN is capable of conferring, and the ONF’s overlords will seek to cultivate and sustain an ecosystem that can deliver parallel hardware and software innovation. Google, for example, has indicated that while it develops its own networking hardware today, it would be amenable to buying OpenFlow switches from the vendor community. Those switches, like to carry lower margins and prices than the gear sold by the major networking vendors, will probably come from ODMs using merchant silicon from Broadcom, Marvell, Fulcrum (Intel), and others.

Money’s in the Software

The major networking vendors are saying that the cleavage of the control and data planes is not a big deal, that it’s not necessary or isn’t a critical requirement for innovation and network programmability. Perhaps there is some merit to their arguments, but there’s no question that the separation of the control and data planes is not in their business interests. If some their assertions have merit, they also are self-serving.

Cisco, as we’ve discussed before, might be able to develop software, but its business model is predicated on the sale of routers and switches. Effectively, it would have to remake itself comprehensively to recast itself as a vendor of server-based controllers (software) and the applications the run on them. A proprietary hardware box, whether a server or switch, isn’t what the ONF wants.

If the ONF’s SDN vision prevails, the money is in software: server-based controllers, applications, management/orchestration frameworks, and so on. Successful vendors not only will have to be proficient at developing software; they’ll also have to be skilled at marketing and selling it. They’ll have to build their businesses around it.

This is the challenge the major networking vendors confront. It’s why they aren’t leading the SDN charge, and it also is why they are attempting to co-opt and subvert it.

Distributed, Hybrid, Northbound: Key Words in Cisco’s SDN Counterstrategy

When it has broached the topic of software-defined networking (SDN) recently, Cisco has attempted to reframe the discussion within the larger context of programmable networks. In Cisco’s conception of the evolving networking universe, the programmable network encompasses SDN, which in turn envelops OpenFlow.

We know by now that OpenFlow is a relatively small part of SDN. OpenFlow is a protocol that provides for the physical separation of the control and data planes, which heretofore have been combined within a switch or router. As such, OpenFlow enables server-based software (a controller) to determine how packets should be forwarded by network elements. As has been mentioned before, here and elsewhere, mechanisms other than OpenFlow could be used for the same purpose.

Logical Outcome

SDN is bigger than OpenFlow. It deals not only with the abstraction of the data plane, but also with higher-layer abstractions, at the control plane and above. The whole idea behind SDN is to put the applications, and the services they deliver, in the driver’s seat, so that the network does not become a costly encumbrance that impedes business agility and operational efficiency. In that sense, Cisco is right to suggest that programmable networks are a logical outcome that can and should result from the rise of SDN.

That said, the devil can always be found in the details, and we should note that Cisco’s definition of SDN, to the extent that it might invoke that acronym rather one of its own, is at variance with the definition that has been proffered by the Open Networking Foundation (ONF), which is controlled by the world’s largest cloud-service providers rather than by the world’s largest networking vendors. Cisco’s understanding of SDN looks a lot more like conventional networking, with a distributed or hybrid control plane instead of the logically centralized control plane favored by the ONF.

This post isn’t about value judgments, though. I am not here to bash Cisco, or anybody else for that matter, but to understand and interpret Cisco’s motivations as it formulates a counterstrategy to the ONF’s plans.

Bog-Standard Switches

Given the context, then, it’s easy to understand why Cisco favors the retention of the distributed — or, failing that, even a hybrid — control plane. Cisco is the market leader in switches and routers, and it owns a lot of valuable real estate on its customers’ networks.  If OpenFlow succeeds, not only in service-provider networks but also in the enterprise, Cisco is at risk of losing the market dominance it has worked so long and hard to build.

Frankly, there isn’t much differentiation to be achieved in bog-standard OpenFlow switches. If the Googles of the world get their way, the merchant silicon vendors all will support OpenFlow on their chipsets, and industry-standard boxes will be available from a number of ODMs and OEMs. It will be a prototypical buyer’s market, perhaps advancing quickly toward commoditization, and that’s not a prospect that Cisco shareholders and executives wish to entertain.

As Cisco comes to grips with SDN, then, it needs to rediscover the sort of leverage that it had before the advent of the ONF.  After all, if SDN is all about putting applications and other software literally in control of networks composed of industry-standard boxes, then network hardware will suffer a significant margin-squeezing demotion in the value hierarchy of customers.  And Cisco, as we’ve discussed before, develops more than its fair share of software, but remains a company wedded to a hardware-based business model.

Compromise and Accommodation 

Cisco would like to resist and undermine any potential market shift to the ONF’s server-based controllers. Fortunately for Cisco, many within the ONF are willing to acquiesce, at least initially and up to a point. A general consensus seems to have developed about the need for a hybrid control plane, which would accommodate both logically centralized controllers and distributed boxes. The ONF’s braintrust sees this move as a necessary compromise that will facilitate a long-term transition to a server-based model. It seems a logical and rational deduction — there’s a lot of networking gear installed out there that does not support the ONF’s conception of SDN — but it’s an opening for Cisco, nonetheless.

Beyond the issue of physical separation of the data plane and the control plane, Cisco has at least one other card to play.  You might have noticed that Cisco representatives have talked a lot during the past couple months about a “northbound interface” for SDN. As currently constituted, OpenFlow is a “southbound” interface, in that serves as a mechanism for a controller to program a switch. On a network diagram, that communication flows downward (hence southbound).

In SDN, a northbound interface would go upward, extending from the switch to the control plane and potentially beyond to applications and management/orchestration software. This is a discussion Cisco wants to have with the industry, at the ONF and elsewhere. Whereas southbound interfaces are all about what is done to a switch by external software, the northbound interface is a conduit by which the switch confers value — in the form of information intrinsic to the network — to the higher layers of abstraction.

Northbound Traffic

For now, the ONF has chosen not to define standard protocols or APIs for northbound interfaces, which could run from the networking devices up to the control plane and to higher layers of abstraction. Cisco, as the vendor with the largest installed base of gear in customer networks, finds itself in a logical position to play a role in helping to define those northbound interfaces.

Ideally, if programmable networks and SDN fulfill their potential, we’ll see the development of a virtuous feedback loop at the highest layers of abstraction, with software programming an underlying virtualized network and the network sending back state and other data that dynamically allows applications to perform even better.

Therefore, the northbound interface will be an important element in the future of SDN. Cisco hopes to leverage it, but more for the sustenance of its own business model than for the furtherance of the ONF’s objectives. Cisco holds some interesting cards, but it should be careful not to overplay them. Ultimately, it does not control the ONF.

As the SDN discourse elevates beyond OpenFlow, watch the traffic in the northbound lanes.

Lessons for Cisco in Cius Failure

When news broke late last week that Cisco would discontinue development of its Android-based Cius, I remarked on Twitter that it didn’t take a genius to predict the demise of  Cisco’s enterprise-oriented tablet. My corroborating evidence was an earlier post from yours truly — definitely not a genius, alas — predicting the Cius’s doom.

The point of this post, though, will be to look forward. Perhaps Cisco can learn an important lesson from its Cius misadventure. If Cisco is fortunate, it will come away from its tablet failure with valuable insights into itself as well as into the markets it serves.

Negative Origins

While I would not advise any company to navel-gaze obsessively, introspection doesn’t hurt occasionally. In this particular case, Cisco needs to understand what it did wrong with the Cius so that it will not make the same mistakes again.

If Cisco looks back in order to look forward, it will find that it pursued the Cius for the wrong reasons and in the wrong ways.  Essentially, Cisco launched the Cius as a defensive move, a bid to arrest the erosion of its lucrative desktop IP-phone franchise, which was being undermined by unified-communications competition from Microsoft as well as from the proliferation of mobile devices and the rise of the BYOD phenomenon. The IP phone’s claim to desktop real estate was becoming tenuous, and Cisco sought an answer that would provide a new claim.

In that respect, then, the Cius was a reactionary product, driven by Cisco’s own fears of desktop-phone cannibalization rather than by the allure of a real market opportunity. The Cius reeked of desperation, not confidence.

Hardware as Default

While the Cius’ genetic pathology condemned it at birth, its form also hastened its demise. Cisco now is turning exclusively to software (Jabber and WebEx) as answers to enterprise-collaboration conundrum, but it could have done so far earlier, before the Cius was conceived. By the time Cisco gave the green light to Cius, Apple’s iPhone and iPad already had become tremendously popular with consumers, a growing number of whom were bringing those devices to their workplaces.

Perhaps Cisco’s hubris led it to believe that it had the brand, design, and marketing chops to win the affections of consumers. It has learned otherwise, the hard way.

But let’s come back to the hardware-versus-software issue, because Cisco’s Cius setback and how the company responds to it will be instructive, and not just within the context of its collaboration products.

Early Warning from a Software World

As noted previously, Cisco could have gone with a software-based strategy before it launched the Cius. It knew where the market was heading, and yet it still chose to lead with hardware. As I’ve argued before, Cisco develops a lot of software, but it doesn’t act (or sell) like software company. It can sell software, but typically only if the software is contained inside, and sold as, a piece of hardware. That’s why, I believe, Cisco answered the existential threat to its IP-phone business with the Cius rather than with a genuine software-based strategy. Cisco thinks like a hardware company, and it invariably proposes hardware products as reflexive answers to all the challenges it faces.

At least with its collaboration products, Cisco might have broken free of its hard-wired hardware mindset. It remains to be seen, however, whether the deprogramming will succeed in other parts of the business.

In a world where software is increasingly dominant — through virtualization, the cloud, and, yes, in networks — Cisco eventually will have to break its addiction to the hardware-based business model. That won’t be easy, not for a company that has made its fortune and its name selling switches and routers.

Fear Compels HP and Dell to Stick with PCs

For better or worse, Hewlett-Packard remains committed to the personal-computer business, neither selling off nor spinning off that unit in accordance with the wishes of its former CEO. At the same, Dell is claiming that it is “not really a PC company,” even though it will continue to sell an abundance of PCs.

Why are these two vendors staying the course in a low-margin business? The popular theory is that participation in the PC business affords supply-chain benefits such as lower costs for components that can be leveraged across servers. There might be some truth to that, but not as much as you might think.

At the outset, let’s be clear about something: Neither HP nor Dell manufactures its own PCs. Manufacture of personal computers has been outsourced to electronics manufacturing services (EMS) companies and original design manufacturers (ODMs).

Growing Role of the ODM

The latter do a lot more than assemble and manufacture PCs. They also provide outsourced R&D and design for OEM PC vendors.  As such, perhaps the greatest amount of added value that a Dell or an HP brings to its PCs is represented by the name on the bezel (the brand) and the sales channels and customer-support services (which also can be outsourced) they provide.

Major PC vendors many years ago decided to transfer manufacturing to third-party companies in Taiwan and China. Subsequently, they also increasingly chose to outsource product design. As a result, ODMs design and manufacture PCs. Typically ODMs will propose various designs to the PC vendors and will then build the models the vendors select. The PC vendor’s role in the design process often comes down to choosing the models they want, sometimes with vendor-specified tweaks for customization and market differentiation.

In short, PC vendors such as HP and Dell don’t really make PCs at all. They rebrand them and sell them, but their involvement in the actual creation of the computers has diminished markedly.

Apple Bucks the Trend 

At this point, you might be asking: What about Apple? Simply put, unlike its PC brethren, Apple always has insisted on controlling and owning a greater proportion of the value-added ingredients of its products.

Unlike Dell and HP, for example, Apple has its own operating system for its computers, tablets, and smartphones. Also unlike Dell and HP, Apple did not assign hardware design to ODMs. In seeking costs savings from outsourced design and manufacture, HP and Dell sacrificed control over and ownership of their portable and desktop PCs. Apple wagered that it could deliver a premium, higher-cost product with a unique look and feel. It won the bet.

A Spurious Claim?

Getting back to HP, does it actually derive economies of scale for its server business from the purchase of PC components in the supply chain? It’s possible, but it seems unlikely. The ODMs with which HP contracts for design and manufacture of its PCs would get a much better deal on component costs than would HP, and it’s now standard practice for those ODMs to buy common components that can be used in the manufacture and assembly of products for all their brand-name OEM customers. It’s not clear to me what proportion of components in HP’s PCs are supplied and integrated by the ODMs, but I suspect the percentage is substantial.

On the whole, then, HP and Dell might be advancing a spurious argument about remaining in the PC business because it confers savings on the purchase of components that can used in servers.

Diagnosing the Addiction

If so, then, why would HP and Dell remain in the PC game? Well, the answer is right there on the balance sheets of both companies. Despite attempts at diversification, and despite initiatives to transform into the next IBM, each company still has a revenue reliance on — perhaps even an addiction to — PCs.

According to calculations by Sterne Agee analyst Shaw Wu, about 70 to 75 percent of Dell revenue is connected to the sale of PCs. (Dell derived about 43 percent of its revenue directly from PCs in its most recent quarter.) In relative terms, HP’s revenue reliance on PCs is not as great — about 30% of direct revenue — but, when one considers the relationship between PCs and related related peripherals, including printers, the company’s PC exposure is considerable.

If either company were to exit the PC business, shareholders would react adversely. The departure from the PC business would leave a gaping revenue hole that would not be easy to fill. Yes, relative margins and profitability should improve, but at the cost of much lower channel and revenue profiles. Then there is the question of whether a serious strategic realignment would actually be successful. There’s risk in letting go of a bird in hand for one that’s not sure to be caught in the bush.

ODMs Squeeze Servers, Too

Let’s put aside, at least for this post, the question of whether it’s good strategy for Dell and HP to place so much emphasis on their server businesses. We know that the server business faces high-end disruption from ODMs, which increasingly offer hardware directly to large customers such as cloud service providers, oil-and-gas firms,  and major government agencies. The OEM (or vanity) server vendors still have the vast majority of their enterprise customers as buyers, but it’s fair to wonder about the long-term viability of that market, too.

As ODMs take on more of the R&D and design associated with server-hardware production, they must question just how much value the vanity OEM vendors are bringing to customers. I think the customers and vendors themselves are asking the same questions, because we’re now seeing a concerted effort in the server space by vendors such as Dell and HP to differentiate “above the board” with software and system innovations.

Fear Petrifies

Can HP really become a dominant purveyor of software and services to enterprises and cloud service providers? Can Dell be successful as a major player in the data center? Both companies would like to think that they can achieve those objectives, but it remains to be seen whether they have the courage of their convictions. Would they bet the business on such strategic shifts?

Aye, there’s the rub. Each is holding onto a commoditized, low-margin PC business not because they like being there, but because they’re afraid of being somewhere else.

Amazon’s Advantageous Model for Cloud Investments

While catching up with industry developments earlier this week, I came across a Reuters piece on Amazon’s now well-established approach toward investments in startup companies. If you haven’t seen it, I recommend that you give it a read.

As its Amazon Web Services (AWS) cloud operations approach the threshold of a $1-billion business, the company once known exclusively as an online bookshop continues to search for money-making opportunities well beyond Internet retailing.

Privileged Insights

An article at GigaOM by Barb Darrow quotes Amazon CEO Jeff Bezos explaining that his company stumbled unintentionally into the cloud-services business, but the Reuters item makes clear that Amazon is putting considerably more thought into its cloud endeavors these days. In fact, Amazon’s investment methodology, which sees it invest in startup companies that are AWS customers, is an exercise in calculated risk mitigation.

That’s because, before making those investments, Amazon gains highly detailed and extremely valuable insights into startup companies’ dynamic requirements for computing infrastructure and resources. It can then draw inferences about the popularity and market appeal of the services those companies supply. All in all, it seems like an inherently logical and sound investment model, one that gives Amazon privileged insights into companies before it decides to bet on their long-term health and prosperity.

That fact has not been lost on a number of prominent venture-capital firms, which have joined with Amazon to back the likes of Yieldex, Sonian, Engine Yard, and Animoto, all of whom, at one time or another, were AWS customers.

Mutual Benefits

Now that nearly every startup is likely to begin its business life using cloud-based computing infrastructure, either from AWS or another cloud purveyor, I wonder whether Amazon’s investment model might be mimicked by others with similar insights into their business customers’ resource utilization and growth rates.

There’s no question that such investments deliver mutual benefit. The startup companies get the financial backing to accelerate its growth, establish and maintain competitive differentiation, and speed toward market leadership. Meanwhile, Amazon and its VC partners get stakes in fast-growing companies that seem destined for bigger things, including potentially lucrative exits. Amazon also gets to maintain relationships with customers that might otherwise outgrow AWS and leave the relationship behind. Last but not least, the investment program serves a promotional purpose for Amazon, demonstrating a commitment and dedication to its AWS customers that can extend well beyond operational support.

It isn’t just Amazon that can derive an investment edge from how their customers are using their cloud services. SaaS cloud providers such as Salesforce and Google also can gain useful insights into how customers and customer segments are faring during good and bad economic times, and PaaS providers would also stand to derive potentially useful knowledge about how and where customers are adopting their services.

Various Scenarios

Also on SaaS side of the ledger, in the realm of social networking — I’m thinking of Facebook, but others fit the bill — subscriber data can be mined for the benefit of advertisers seeking to deliver targeted campaigns to specific demographic segments.

In a different vein, Google’s search business could potentially give it the means to develop high-probability or weighted analytics based on the prevalence, intensity, nature, and specificity of search queries. Such data could be applied to and mined for probability markets. One application scenario might involve insiders searching online to ascertain whether prior knowledge of a transaction has been leaked to the wider world. By searching for the terms in question, they would effectively signal that an event might take place. (This would be more granular than Google Trends, and different from it in other respects, too.) There are a number of other examples and scenarios that one could envision.

Getting back to Amazon, though, what it is doing with its investment model clearly makes a lot of sense, giving it unique insights and a clear advantage as it weighs where to place its bets. As I said, it would be no surprise to see other cloud providers, even those not of the same scale as Amazon, consider similar investment models.

The Politics of OpenFlow

“There’s something happening here, but what is ain’t exactly clear.”  —  Buffalo Springfield, “For What It’s Worth.”

Software-defined networking (SDN) and its protocol of choice, OpenFlow, have been in the news for the past couple weeks, and I suspect we’ll have to get used to it. I feel quite comfortable claiming that neither is a fad, and the salient question is not whether they will take off but how far and how fast they will go.

Those, by the way, are good questions. To get answers, I think we first have to understand the technology and its applicability — as many are doing — and we also have to understand who’s behind the SDN curtain, why those particular entities are driving change, and how serious they are about realizing their objectives.

Strange as it might seem, we can benefit from an understanding of the political economics of OpenFlow. By political economy, I refer to the industry politics that are the driving force behind the economics of OpenFlow-based SDNs.

New Industry Dynamics

I’m pondering this subject increasingly because, apologies to Buffalo Springfield, something is happening here that is new and strange. It is happening because the industry — its technologies and markets — is evolving toward new business structures and away from old ones.

I’ll try not to bore you, but let’s briefly set the context. In the old client-server and even in the first wave of the Internet or the Web-based era of distributed computing,  the vendors were in the catbird seats. To varying degrees, everybody — service providers, enterprises, SMBs — looked to them for direction and guidance, not to mention solutions. If the vendors weren’t exactly trusted by their customers, they were needed and valued.

Enterprises Lacked Political Clout

Enterprises come in all shapes and sizes, and they span numerous vertical markets. For that reason, they tend not have overwhelming commonality of interests, and they don’t organize themselves in common cause.  As we have seen, that’s not the case with today’s largest cloud service providers. They are similar to one another in many operational and business respects, they have common interests, and they are working in concert to pursue shared business objectives.

Today we all talk about cloud computing, which has been hyped to death, but one factor that perhaps hasn’t been appreciated fully is that it is a major political change agent for the industry. With cloud computing, power shifts from the vendor community to the service-provider community. As applications and services move to the cloud, market value accompanies them. As Google and Facebook and various other cloud-service providers gain scale, they also gain economic and political power within the industry.

So, what does that mean? Well, it can mean many things, but what it means for the networking industry is that the game is changing, and in ways that must be unnerving to the boards of directors at companies such as Cisco Systems.

Google as Pioneer and Extreme Example

Let’s take Google as an example, albeit an admittedly extreme one. Google tends to make its own technology infrastructure rather than buy it from vendors. It makes it own servers, and it was one of the first service providers (as Andrew Schmitt uncovered a few years ago) to design and build its own switches. As I think about the likely origins of the Open Networking Foundation (ONF), the current manifestation of software defined networking, and the development of OpenFlow as a mechanism for realizing the business benefits of SDN, I believe we need to look back to Google’s pioneering efforts to build its own networking infrastructure. In retrospect, that was a watershed moment, and it resulted in what we’re seeing today with SDNs and OpenFlow. It was doubtless motivated by the same business and technology considerations.

To reiterate, as cloud computing rises, technology’s hierarchy of power also changes. As mentioned above, as SMBs and enterprises increasingly move applications to the cloud, where they can be delivered as services by operators such as Google and others of its ilk, two things happen: enterprise-oriented vendors find potentially themselves with a smaller market to serve, and the cloud-service providers begin to assert themselves in a number of ways, which includes setting the technology agenda for the industry.

The Open Network Foundation (ONF), for example, is run by and for service-provider community. Networking vendors do not control or drive that organization, and they never will. It is controlled by the six founding members, and they’re all major service providers. Make no mistake, the organization was constructed that way for a reason, with a clear purpose in mind. Those who politically control an organization necessarily set its agenda. The agenda of the ONF, and certainly the development of OpenFlow, is skewed definitively toward their interests. At this point, the ONF’s conception of software-defined networking is not concerned with enterprise needs or requirements. It might get there some day. I know the investors behind Big Switch Networks are hoping it does. But it’s not there now.

Inexorable Cloud Drivers 

I said earlier that Google, in this context, was an extreme example of a service provider. Not every cloud purveyor will design and deliver its own switches, and few and far between would try to tackle the challenge of core routing, as Google seems to be doing now. Still, Google and others behind the ONF have evinced enlightened self-interest. They know that the more they can move the world toward a model of highly efficient and effective cloud-based IT infrastructure (servers, storage, networking), predicated on bare-bones industry-standard hardware and orchestrated by an application-driven software-management layer, the more they will drive down their cost of production and operation. As that is achieved, they won’t just lower their own cost structures, but they will hasten the shift of consumer and enterprise applications and services to the public cloud. It’s a matter of scale, cost, and market dynamics.

NTT sees it, so do all the others. Even those who haven’t joined the Open Networking Foundation, such as Rackspace, are seeking to leverage OpenFlow.

It’s not that these service providers dislike Cisco or Juniper. As I said before, it’s just business. What Cisco and Juniper do, how they work and what they do, might have sufficed before, but it that is not an optimal model for these service providers now — or in the future.

I’m not a stock-market prognosticator, but I realize this scenario has implications for investors in networking companies. Some vendors are more exposed than others to this shift and to these developments. I will deal with those companies and their changed circumstances in subsequent posts. I don’t want to muddy the waters by delving into company-specific fortunes at this time. Suffice it to say, there’s a reason why Juniper Networks and Cisco Systems, both of which have significant exposure to the service-provider community, are scrambling to get on the OpenFlow bandwagon. It’s better to part of this parade than to be left behind, and maintaining a presence in major service-provider accounts is better than having no presence at all.

Nobody Dies, but Some Get Hurt 

Don’t get me wrong. I realize that the enterprise is a big networking market — still the biggest of all — and that the cloud and its technological agenda won’t vaporize that market overnight. Nobody is going to get “killed” or fatally disabled in the next few months, or even probably in the next few years. (I hate that “killer” talk people throw around on the Interwebs. It’s hype, and it doesn’t advance any sort of meaningful discourse or understanding at all.)

For that reason, I think it’s entirely relevant to discuss the current shortcomings of OpenFlow-based SDNs for enterprise networks. Along those lines, Ethan Banks offered some cogent thoughts yesterday on the topic after taking in the Open Flow Symposium.

As for me, I see what the progenitors of the ONF are trying to achieve. I understand why they are doing it, and I think it’s a big deal in a number of respects. As we move increasingly to the cloud, the major service providers, as represented by the demographics of the ONF board members, are moving to the fore, asserting their growing power.

ONF Deadly Serious About OpenFlow-Based SDNs

Yes, I’m back for further cogitation on software-defined networking (SDN) and OpenFlow.

As I wrote in my last post, relating to Cisco’s recent support for OpenFlow, I wasn’t able to attend the Open Networking Summit held last week at Stanford University.  I have, however, been reading coverage of the conference, and I am now convinced of a few fundamental SDN market realities.

Let’s start with who’s steering this particular SDN ship. The Open Networking Foundation (ONF) has been the driving force behind OpenFlow-based SDN. As I’ve written before, perhaps to the point of mind-numbing redundancy, the ONF is controlled not by networking vendors, but by the behemoths of the cloud service-provider community.

Control and the Power 

Networking vendors can be (and are) ONF members, but one needs to appreciate their place in the foundation’s hierarchy.  They are second-class citizens, and they are not setting the agenda. One more time, I will list the “founding and board members” of the ONF: Deutsche Telekom, Verizon, Google, Facebook, Microsoft, and Yahoo. Microsoft is there by dint of its status as a cloud service provider, not because it is a technology vendor.

Any doubts about where control and power reside within ONF were put to definitive rest in a recap of a third day of the Open Networking Summit provided by Dell’s Art Fewell on the NetworkWorld website:

“ . . . . Open Networking Foundation (ONF) Director Dan Pitt gave an excellent presentation that demonstrated that the ONF put a lot of thought into how they designed and structured the organization to incorporate lessons learned from older standards bodies, software communities and from the devops and open source movements. He noted that the ONF’s charter would not allow technology vendors to serve on the board of directors, but rather it should be governed by the network operators who have to live with the results. Working group chairs are assigned by the board, and a system of checks and balances has been put into place to try to prevent the problems that some standards organizations have become notorious for.”

It’s All About the Money

The message is clear. The network operators know what they want from SDN and OpenFlow, and they believe they know how to get it. What’s more, they don’t want the networking vendors compromising, subverting, or undermining the result.* (*Not that they’d do that sort of thing, of course.)

What, then, is the overriding objective these big network operators have in mind? Well, it’s to save money, as I explained in my previous post. SDN, and especially SDN enabled by an industry-standard protocol such as OpenFlow, is perceived by the major service providers as a means of substantially reducing network-related capital and, more to the point, operating expenditures. Service-provider executives, especially the mahogany-row bean counters, get excited about that sort of thing.

As Stacey Higginbotham notes, recounting an Open Networking Summit address given by a representative of Verizon:

“Stuart Elby, VP and network architecture & technology chief technologist for Verizon Digital Media Services, laid out how the promise of software-defined networking could make the company’s cost curve match its revenue by cutting down on the need for expensive gear that is costly to buy and even more costly to operate. In a conversation before his presentation, Elby explained how Verizon’s network can view every single packet on the network, but how keeping track of those packets is both a big data problem and expensive from a network management perspective.”

Verizon’s Compelling Chart

Verizon is not alone. Every one of the founding players in ONF sees the same business value in OpenFlow-enabled SDN. In the eyes of the ONF’s most powerful players, conventional network infrastructure is holding back substantial business benefits. It’s not personal, but it is business. And it is how and why major tectonic shifts in this industry come about.

Along those lines, Elby presented a visually powerful illustration that makes clear just how big an issue network-related costs are for Verizon. The chart is reproduced in Higginbotham’s article at GigaOM and in Fewell’s piece at NetworkWorld. If you haven’t seen it, I suggest you take a look. It really is worth a thousand words, but I’ll summarize as follows: Verizon’s network operating costs soon will surpass its revenues, resulting in what Verizon quaintly calls a “non-sustainable business case.” Therefore, there is an urgent need for a solution that lowers network-equipment expenditures, through utilization of off-the-shelf hardware, and enables a business case that better aligns operating costs with revenues. Verizon sees SDN and OpenFlow as the ticket to “inexpensive feature insertion for new services and revenue uplift.”

Verizon is not alone. It’s safe to say the others on the ONF board are dealing with variations of the same problem and are seeking similar solutions.

Google Goes Further

Google, for one, isn’t stopping at switches. As Higginbotham explored in an earlier post at GigaOM last week, Google is a fervent proponent of Quagga and the Open Sourcing Routing Project. The search giant’s goals are practical, namely  “cheaper, highly programmable routers it can use in its (core) network.” Called the Open LSR, Google’s router, as Higginbotham writes, is “an open-source router that consists of a switch made with merchant silicon and running Open vSwitch that talks to a server that has an OpenFlow-based controller and uses Quagga to generate the routing tables and forwarding information.”

As if the theme needs further belaboring, it’s all about taking cost out of network infrastructure. Google is working with others in the service-provider community to make its low-cost routing dream a reality.

It is clear, then, that the largest service providers, and perhaps may smaller ones besides, want to gain more control over their networks and with the costs associated with them. They have constructed the Open Network Foundation with a clear purpose in mind, they see SDN and Open Flow as solutions to a clearly articulated business problem, and they seem determined to see it through to fruition.

What About the Enterprise?

What remains to be seen is how willing enterprises will be to go along for the SDN ride. This is a point that was hammered home by Peter Cristy of the Internet Research Group, who, as reported by Fewell, told the audience at the Open Networking Summit that SDN and OpenFlow are likely to face significant challenges in cracking the enterprise market. Cristy’s points were valid. His most salient observations were that there have been few OpenFlow “killler apps,” and that enterprises do not favor “reproducing the same thing with new technology,” especially if that technology is new and complicated.

He’s right. But we have to remember that the ONF is captained by service providers, and they are not leading their particular SDN charge because they are motivated by altruistic concern for enterprise networks and their stewards. No, for now at least, the ONF’s conception of SDNs will be applicable to the demographic represented by the composition of the ONF board. Enterprises will have to wait, it seems, and that’s probably good news for the established order of networking vendors, especially for Cisco Systems.

Assessing Market Implications

Still, I have to wonder. Cristy is correct to note that the enterprise accounts for the “biggest part of the networking market.” Nonetheless, times are changing. As more applications move to the cloud, and to cloud service providers, SDN and presumably OpenFlow are likely to increasingly affect the top and bottom lines of networking vendors.

Those companies — Cisco, Juniper, and all the rest — have to keep a wary eye on SDN developments. Even if networking vendors eventually lose a chunk of business at network service providers, they’ll still have the enterprise, presuming they can position themselves correctly and anticipate change rather than react belatedly to it.

There’s a lot at stake as this story plays out in the months and years ahead.