Cisco Puts ACE in the Hole (or Maybe Not)

Although Cisco reportedly confirmed that it will discontinue further development of its Application Control Engine (ACE), a Cisco representative now says that it isn’t the case, and that ACE will be developed further.

Regardless of what Cisco eventually does with ACE, we have not seen the last of the company in the application-delivery controller (ADC) market. In fact, the latest indications, as published in articles at SearchNetworking and The Register, suggest that Cisco, like Arnold Schwarzenegger in The Terminator, will be back.

The salient question is whether Cisco’s next foray into the ADC market, regardless of the form it takes, will produce results any different from its previous efforts, which were catalogued by yours truly about two years ago. Indeed, Cisco has been beaten consistently and repeatedly by F5 Networks in load balancing. Cisco’s losing streak goes back more than a decade, and it is likely to continue if the company stumbles back into the market halfheartedly.

While there is no question that F5 has gotten the better of Cisco continually in load balancing, a more interesting question relates to why Cisco has failed. One line of reasoning suggests that Cisco neither understands nor appreciates Layer 4-7 network services, including load balancing and WAN optimization. Cisco, this argument asserts, is a switching and routing company, proficient at layers 2 and 3, but woefully out of its comfort zone higher up the stack.

Bigger Picture

There’s some legitimacy to that argument, but it doesn’t provide a complete picture. More often than not, Cisco’s load-balancing products and technologies were predicated on the fruits of acquisitions rather than on organic innovation. That is true going all the way back to the long-dead LocalDirector, which was based on technology Cisco obtained through the acquisition of Network Translation Inc. in 1996. Subsequent to that, Cisco acquired former F5 competitor ArrowPoint Communications for $5.7 billion in 2000.  The personnel in these load-balancing companies clearly understood network services, even if the old-guard switching and routing stalwarts at Cisco did not.

So, we’re left with two possibilities. Cisco made bad acquisition choices, effectively acquiring the wrong load-balancing companies, or Cisco failed to execute properly in taking the products and technologies of the acquired companies to market. I’m leaning toward the latter scenario.

Cisco’s primary problem in areas such as load balancing and WAN optimization, as it has been expressed to me by former Cisco executives, is that the company strategically understands that it needs to play in these markets, but that it invariably fails to make the commitment necessary to success. Why is that?

A Matter of Focus and Priority

It comes down to market sizes and business priorities. Switching and routing always ruled the roost, and the resources, at Cisco. That’s still true today, perhaps even to a greater extent now that the company is coming under renewed attack in its core markets after failing to break new ground in many of what CEO John Chambers called the company’s market adjacencies. (Flip, anyone?)

Fundamentally, nothing seems to have changed. Cisco might take another run at ADCs, but there’s no reason to suppose that it would end differently this time unless Cisco makes a sustained and uncompromising commitment to the market and the technologies. Nothing less will do.

Cisco can be sure that is ADC competitors, as in the past, will not give it any breaks.

Questioning SDN Cynicism

A few months ago, I noticed that the networking cognoscenti were becoming jaded about software-defined networking (SDN). To be fair, the networking cognoscenti can skew toward disgruntlement, so it was no surprise to see this restive bunch cast a jaundiced eye toward networking’s greatest, latest hope.

I consider myself among the skeptical and wary, always cognizant that vendors can be inclined to advance a self-serving agenda that sometimes is designed to satisfy their own near-term interests over the long-term objectives of their customers. That works particularly well when the vendors can trick the customers into believing that they’re actually looking out for them. As our ancient forebears knew, caveat emptor was more than a catchphrase.

Asking Why

All of which brings me to a puzzling aspect of the current disaffection with SDN, expressed most recently in a highly readable and strongly recommended post by Ethan Banks of PacketPushers fame. My question, which I put to Banks to and to everyone else for whom SDN has become an annoyance, is simple: Are you really upset with SDN, or are you actually frustrated with the way the term has been used and abused by the vendor community?

It’s not an academic or an idle question.

One should remember that SDN, properly defined and understood, is a creation of a customer-centric consortium, the Open Networking Foundation (ONF), not a marketing or technical construct espoused by a given networking vendor or even by a group of vendors. If the term “SDN” is being bastardized and demeaned, it is not the ONF that is doing it. More directly, if the term is being cheapened, the devaluation is occurring at the hands of vendors.

But why? There are at least two possibilities. One is that certain networking vendors want to exploit the positive connotations, the afterglow, that surrounded software-defined networking (SDN). According to this theory, the damage they’re inflicting to the SDN brand is unintentional and ironic: They wanted to ride SDN’s relatively pristine coattails, not pull it into a seedy gutter of disrepute. I would be inclined to accept this theory if vendors adopted SDN definitions that accorded with that of the ONF, but. for the most part, that’s not what’s happened.

Agents Provocateurs: Back in Action 

Instead, vendors typically recast SDN in forms that correspond with product roadmaps and company-specific strategic objectives.  The result has been market confusion and cynicism, understandably so. When a term is spun to mean practically anything to anyone, it risks losing its specificity and its relevance.

Allow me suggest that at least a few vendors would be neither inconvenienced nor unduly troubled to see SDN’s identity fractured and splintered like a broken mirror.  It would not be the first time that fear, uncertainty, and doubt were deployed as agents provocateurs in a commercial context.

Nonetheless, coming back to my question above, I would counsel that we think carefully about whether our annoyance is really with SDN or with the way the term “SDN” is being manipulated and distorted by the vendor community.

As always, it is helpful to diagnose not only what is happening, but to try to understand why it is happening, too.

A Special Thank You

I wish to offer a special thank  you to all those who extended condolences last week.  I was and remain truly appreciative of your kind thoughts and warm sentiments.

Northbound API: The Standardization Debate

During the last several months, several extremely informative articles and posts have been written about the significance of the northbound API (or NB API) within the context of software-defined networking (SDN).

We’ve seen two posts on the topic at SDN Central, one written in April by David Lenrow and another written by Roy Chua in early July.  Brent Salisbury, on his blog NetworkStatic, offered an excellent exegesis on the northbound API in June, and he touched on the topic again in a subsequent post in July that dealt with how he believes SDN APIs will evolve. At GigaOm, Stacey Higginbotham also has written on the subject, as have I both here and at TechTarget’s SearchNetworking.

Recently, Greg Ferro, of EtherealMind renown, provided an instructive overview on SDN APIs, opining that it is “unlikely that Northbound APIs will never standardise but I’m not aware of any initiatives in this area.”

I don’t know whether northbound APIs, as Greg suggests, will never standardize, but I do know that most knowledgeable observers (including the aforementioned parties) believe that there should no headlong rush toward standardization. The consensus is that SDN’s northbound APIs should be given an opportunity to flourish first, and that the market ultimately should vote with its feet and with its wallets.

Too Early?

That said, there are those who believe standards bodies should play a role, even at this nascent stage, in defining SDN’s northbound API.  In fact, the matter was raised yesterday on a discussion thread for the IETF’s software-driven network protocol (SDNP) BOF mailing list, where some argued that the Open Networking Foundation’s (ONF) reluctance to begin standardization work on the northbound API — the ONF reportedly will incorporate northbound-API discussions into deliberations of its recently formed architecture workgroup — opened the door for IETF involvement.

Often, but not always, proponents of near-term northbound-API standardization are representatives of legacy vendors familiar with the standards-definition process. (At this point, I feel strangely compelled to invoke the quote often misattributed to Otto von Bismarck regarding the similarity of laws to sausages: “Laws are like sausages. You should never watch them being made.” I believe this maxim also applies to IETF standards.)

The point here, though, isn’t to render a value judgment on who’s right and who’s wrong. What’s salient is that there is stark disagreement on whether the question of the northbound API can and should be settled by market forces or by vendor comity (and committee). Watching to see which players line up on either side of the divide, and how they defend their positions, will be instructive.

Back Soon

I’m still around. I had plans this week to write about several recent industry announcements and developments. I still intend to get around to writing those posts. 

Unfortunately, I first must deal with a death in my immediately family. I’ll be back soon. 

Avaya Executive Departures, Intrigue Continue

Like many other vendors, Avaya showed off its latest virtualized wares at VMworld in San Francisco this week. While putting its best face forward at VMware’s annual conference and exhibition, Avaya also experienced further behind-the-scenes executive intrigue.

Sources report that Carelyn Monroe, VP of Global Partner Support Services, resigned from the company last Friday. Monroe is said to have reported to Mike Runda, SVP and president of Avaya Client Services. She joined Avaya in 2009, coming over from Nortel.

Meanwhile, across the pond, Avaya has suffered another defection. James Stevenson, described as a “business-services expert” in a story published online by CRN ChannelWeb UK, has left Avaya to become director of operations for reseller Proximity Communications.

Prior to the departures of Monroe and Stevenson, CFO Anthony Massetti bolted for the exit door immediately after Avaya’s latest inauspicious quarterly results were filed with the Securities and Exchange Commission (SEC). Massetti was replaced by Dave Vellequette, who has a long history of of working alongside Avaya CEO Kevin Kennedy.

In some quarters, Kennedy’s reunion with Vellequette is being construed as a circle-the-wagons tactic in which the besieged CEO attempts to surround himself with steadfast loyalists. It probably won’t be long before we see a “Hitler parody” on YouTube about Avaya’s plight (like this one on interoperability problems with unified communications).

Amazon-RIM: Summer Reunion?

Think back to last December, just before the holidays. You might recall a Reuters report, quoting “people with knowledge of the situation,” claiming that Research in Motion (RIM) rejected takeover propositions from Amazon.com and others.

The report wasn’t clear on whether the informal discussions resulted in any talk of price between Amazon and RIM, but apparently no formal offer was made. RIM, then still under the stewardship of former co-CEOs Jim Balsillie and Mike Lazaridis, reportedly preferred to remain independent and to address its challenges alone.

I Know What You Discussed Last Summer

Since then, a lot has happened. When the Reuters report was published — on December 20, 2011 — RIM’s market value had plunged 77 percent during the previous year, sitting then at about $6.8 billion. Today, RIM’s market capitalization is $3.7 billion. What’s more, the company now has Thorsten Heins as its CEO, not Balsillie and Lazardis, who were adamantly opposed to selling the company. We also have seen recent reports that IBM approached RIM regarding a potential acquisition of the Waterloo, Ontario-based company’s enterprise business, and rumors have surfaced that RIM might sell its handset business to Amazon or Facebook.

Meanwhile, RIM’s prospects for long-term success aren’t any brighter than they were last winter, and activist shareholders, not interested in a protracted turnaround effort, continue to lobby for a sale of the company.

As for Amazon, it is said to be on the cusp of entering the smartphone market, presumably using a forked version of Android, which is what it runs on the Kindle tablet.  From the vantage point of the boardroom at Amazon, that might not be a sustainable long-term plan. Google is looking more like an Amazon competitor, and the future trajectory of Android is clouded by Google’s strategic considerations and by legal imbroglios relating to patents. Those presumably were among the reasons Amazon approached RIM last December.

Uneasy Bedfellows

It’s no secret that Amazon and Google are uneasy Android bedfellows. As Eric Jackson wrote just after the Reuters story hit the wires:

Amazon has never been a big supporter of Google’s Android OS for its Kindle. And Google’s never been keen on promoting Amazon as part of the Android ecosystem. It seems that both companies know this is just a matter of time before each leaves the other.

Yes, there’s some question as to how much value inheres in RIM’s patents. Estimates on their worth are all over the map. Nevertheless, RIM’s QNX mobile-operating system could look compelling to Amazon. With QNX and with RIM’s patents, Amazon would have something more than a contingency plan against any strategic machinations by Google or any potential litigiousness by Apple (or others).  The foregoing case, of course, rests on the assumption that QNX, rechristened BlackBerry 10, is as far along as RIM claims. It also rests on the assumption that Amazon wants a mobile platform all its own.

It was last summer when Amazon reportedly made its informal approach to RIM. It would not be surprising to learn that a reprise of discussions occurred this summer. RIM might be more disposed to consider a formal offer this time around.