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.

Advertisement

VCs Weigh SDN’s Risks and Rewards

I’ve been thinking about a month-old post that Matthew Palmer wrote on the SDNCentral website.

In his post, Palmer considers that Arista, Insieme, and Vyatta were not financed by traditional venture capitalists. He further questions to what extent venture capitalists will plow money into the SDN space. He comes to the conclusion that it is “hard to believe there will be a large number of SDN startups being funded” by VCs.

My objective here is not to challenge Palmer’s conclusion, which seem about right. Instead, I want to examine his assumptions to see whether I can add anything to the discussion.

Slow-Growth Dead Zone

For a long time, VCs have eschewed the networking market. In recent years, Arista Networks emerged as the only new Ethernet-switching vendor to crash the established vendors’ party. Arista, as Palmer points out, was funded by its founders, not by VCs, who generally perceived networking, especially the enterprise variant, as a slow-growth dead zone controlled and dominated by Cisco Systems.

Meanwhile, the VCs had unfortunate experiences in the network-access control (NAC) market, where they sought to make bets in an area that was seen as peripheral to the big vendors’ wheelhouses.

As for SDN today, Palmer thinks most of the major VCs have done their bidding, and he believes Sequoia and Kleiner Perkins will fill out the field shortly. Beyond that, he doesn’t see much action.

Freeze Frame

He comes to that conclusion partly because of Cisco’s longstanding domination of the networking market. Writing that “Cisco learned a long time ago how to freeze markets and make markets look unattractive to competitors and investors,” Palmer believes the networking giant has put “everyone on notice” with its Insieme spin-in venture.  He believes Insieme, and whatever else Cisco does in SDN, will shut the door on SDN startups that aren’t already on the market with credible products and technologies that solve customer problems.

Perhaps VCs, as they have done in the recent past, will refrain from betting against the industry giant. That said, there already has been more VC activity in SDN than we’ve seen in network infrastructure for quite some time. In that respect, SDN demonstrably is different from the networking developments that have preceded it.

It’s different in others ways, too. I know I’ve hammered the same nail repeatedly in the past, but, at the risk of obsessive redundancy, I will do so again: The Open Networking Foundation (ONF) represents a powerful customer-driven dynamic that effectively challenges the vendor-led hegemony that has typified most networking markets and associated standards bodies. The ONF is run by and for service providers. Vendors are excluded from its board of directors, and their contributions are carefully circumscribed to conform with the dictates of the board.

Formidable Power

The catch is that the ONF is all about the needs and requirements of cloud service providers. The enterprise isn’t a primary consideration, though the development of enterprise-market demand for SDN products and technologies could further the strategic interests (economies of scale, innovation, vendor support, etc.) of the service-provider community.

Cisco is a formidable power, but it can’t impose its will on the ONF. In that respect, at least in the service-provider space, SDN is different from preceding network markets, such as Ethernet switching, which were basically incremental advancements in an established market model.

Call me crazy, but I believe that market and financial analysts should begin modeling scenarios in which the growth of SDN cuts into the service-provider revenues and margins of Cisco and Juniper. This will be particularly true in the cloud-service provider (IaaS) space initially, but it is likely to grow into other areas over time.

Enterprise Bulwark

The enterprise? That’s a tougher nut for SDN, for the reason I’ve cited earlier (ONF’s lack of an enterprise mandate), and for others as well. For starters, most enterprises don’t have the resources or the motivation (business case) to move away from networking models and relationships that have served them well.  As SDN evolves over time, that situation could change. For now, though, SDN is more a curiosity for enterprises than something they are considering for wholesale adoption.

Cisco and the other established networking vendors know the enterprise is safer ground for whatever SDN strategy or counterstrategy they present. In this respect, what Palmer terms “Insieme FUD” and other similar tactics are likely to be effective in the near term (the next two years.)

I really can’t quibble with Palmer’s conclusion — as I wrote above, it feels about right — but I think the VC investments we’ve seen heretofore in SDN already suggest that it is perceived differently from the linear networking markets that have preceded it.   I also believe there’s reason to think that SDN will lead to significant disruptions to the provision of networking solutions in the service-provider space.

How far can it go in the enterprise? For now, prospects are murky, but the game is in the early stages, and much will depend on how the SDN ecosystem evolves as well as on how effective Cisco and others are at leveraging the advantages of incumbency.

Tidbits: Oracle-Arista Rumor, Controller Complexity, More Cisco SDN

This Week’s Rumor

Rumors that Oracle is considering an acquisition of Arista Networks have circulated this week. They’re likely nothing more than idle chatter. Arista has rejected takeover overtures previously, and it seems determined to go the IPO route.

Controller Complexity

Lori MacVittie provides consistently excellent blogging at F5 Networks’ DevCentral. In a post earlier this week, she examined the challenges and opportunities facing OpenFlow-based SDN controllers. Commenting on the code complexity of controllers, she writes the following:

This likely means unless there are some guarantees regarding the quality and thoroughness of testing (and thus reliability) of OpenFlow controllers, network operators are likely to put up a fight at the suggestion said controllers be put into the network. Which may mean that the actual use of OpenFlow will be limited to an ecosystem of partners offering “certified” (aka guaranteed by the vendor) controllers.

It’s a thought-provoking read, raising valid questions, especially in the context of enterprise customers.

Cisco SDN

Last week, Cisco and Morgan Stanley hosted a conference call on Cisco’s SDN strategy. (To the best of my knowledge, Morgan Stanley doesn’t have one — yet.)  Cisco was represented on the call by David Ward, VP and chief architect of the company’s Service Provider Division; and by Shashi Kiran, senior director of market management for Data Center/Virtualization and Enterprise Switching Group.

The presentation is available online. It doesn’t contain any startling revelations, and it functions partly as a teaser for forthcoming product announcements at CiscoLive in San Diego. Still, it’s worth a perusal for those of you seeking clues on where Cisco is going with its SDN plans. If you do check it out, you’ll notice on side three that a number of headlines are featured attesting to the industry buzz surrounding SDN.  Two bloggers are cited in that slide: Greg Ferro (EtherealMind) and, yes, yours truly, who gets cited for a recent interpretation of Cisco’s SDN maneuverings.

Still Early Days in SDN Ecosystem

Jason Edelman has provided a helpful overview of the software-defined networking (SDN) ecosystem and the vendors currently active within it. Like any form chart, though, it’s a snapshot in time, and therefore subject to change, as I’m sure Edelman would concede.

Still, what Edelman has delivered is a useful contextual framework to understand where many vendors stand today, where “stealth” vendors might attempt to make their marks shortly, and where and how the overall space might evolve.

Edelman presents the somewhat-known entities — Nicira, Big Switch, NEC, and Embrane (L4-7) at the applications/services layer — and he also addresses  vendors providing controllers, where no one platform has gained an appreciable commercial advantage because the market remains nascent.  He also covers the “switch infrastructure” vendors, which include HP Networking, Netgear, IBM, Pica8, NEC, Arista, Juniper, and others. (In a value-based analysis of the SDN market, “switch infrastructure” is the least interesting layer, but it is essential to have an abundance of interoperable hardware on the market.)

Cards Still to be Played

The real battle, from which it might take considerable time for clears winners to emerge, will occur at the two upper layers, where controller vendors will be looking to win the patronage of purveyors of applications and services. At the moment, the picture is fuzzy. It remains possible that an eventual winner of the inevitable controller-market shakeout has yet to enter the frame.

In that regard, look for established networking players and new entrants to make some noise in the year ahead. Edelman has listed many of them, and I’ve heard that a few more are lurking in the shadows. Names that  are likely to be in the news soon include Plexxi, LineRate Systems (another L4-7 player, it seems), and Ericsson (with its OpenFlow/MPLS effort).

These are, as the saying goes, early days.

Cisco’s Latest Spin-In Reportedly Poaching Aggressively (And Not At Cisco This Time)

Insieme (everybody keeps calling it “Insiemi,” but I have been told that the correct spelling is the former) is back in the spotlight again, even though nobody can say with any precision exactly what the Cisco spin-in venture has been mandated to do.

Om Malik is the latest industry observer to attempt to shed light on Insieme. He doesn’t provide many specifics on what Mario Mazzola, Luca Cafiero, Prem Jain and their band of merry engineers will be building — “a new very high-speed data center switch along with a software management platform,” Om offers — but he does deliver some interesting insight into how the spin-in venture is recruiting new members to its team.

Om’s sources tell him that Insieme is aggressively raiding the engineering ranks of Cisco competitors, allegedly offering nearly $2 million a pop as an inducement — and that’s quite an inducement — to engineers and executives at competing companies willing to jump ship and join the networking pirates at the Cisco-sponsored venture.

Although Om, through his sources, originally reported significant executive defections from Nicira (four) and Arista (four), he has since revised his post to indicate that Insieme has managed to snare five engineers in total, plucked from Arista, Nicira, Big Switch Networks, and Cumulus Systems. Other engineers at those companies are said to have declined offers to join the Cisco spin-in venture.

Change of Tack

Nonetheless, this tactic marks a change for Cisco spin-in creations fronted by Mazzola, Cafiero, and Jain. Usually, their ventures plunder from within the ranks of Cisco rather than from beyond the walls of the networking giant. As written here and elsewhere previously, the spin-in ventures’ practice of recruiting Cisco’s best and brightest — or at least those seen as most useful to the project at hand — has engendered envy and resentment among those not tapped for the gravy train.

To be sure, Cisco’s previous spin-in ventures — including the Mazzola-helmed, Italian-themed Andiamo and Nuova — included engineers recruited from company’s other than Cisco. Still, there’s no question that Mazzola and friends poached extensively from the engineering teams with which they were most familiar. One wonders whether Chambers and the Cisco executive team might be trying to discourage that practice this time around.

Another plausible explanation is that the hardware-heavy Insieme engineering team is looking for engineering capabilities in software, and specifically in software-defined networking (SDN), that are better found at the aforementioned companies than at Cisco itself.

Either way, the incipient Insieme appears to be roiling the network-engineering waters in Silicon Valley.

Further Thoughts on Cisco’s Latest Spin-In Venture

This is a follow-up post to my last missive regarding Cisco’s latest reported spin-in venture, Insieme (not Insiemi, apparently). As you will recall, we had heard for some time that Cisco’s masters of the spin-in venture were getting back in the saddle for at least one more stretch run.

The question had become not whether they’d come back, but what they would put on the playlist for their reunion. Now, as indicated in an article in the New York TImes, the widely held assumption is that Insieme will provide Cisco’s answer to software-defined networking (SDN).

But, as we know, SDN means different things to different vendors. Given the composition and capabilities of the team at Insieme, I wouldn’t expect this group to recreate the sort of logically centralized control plane and server-based programmable networking that the likes of Nicira and Big Switch Networks have championed.

ASICs in the Mix 

After all, the central protagonists at Insieme — Mario Mazzola, Luca Cafiero, Prem Jain — are hardware engineers. Throughout their long, storied, and illustrious careers, they have built switches. There is no reason to think they will be cast against type in this particular venture. A variation on what they’ve done in their previous spin-in ventures for Cisco —  Andiamo, which was responsible for Cisco’s storage-area networking (SAN) switches, and Nuova, which provided Cisco with its Nexus data-center switches — is probably what they’ll do this time, too.

Admittedly, there is some software talent on the Insieme roster. Network World’s Jim Duffy reported that Ronak Desai, the architect of Cisco’s NX-OS FabricPath and Virtual Device Context software, and of the MDS SAN switch operating system, is on the team. Michael Smith, a distinguished engineer who worked on Cisco’s Nexus 1000v virtual switch, also might be part of the Insieme squad.

Still, John Chambers recently reiterated Cisco’s unswerving commitment to the propriety switching ASIC, which Cisco sees a point of differentiation against Arista Networks and others. Chambers’ words suggest that Cisco isn’t about to get the newfangled SDN religion. In fact, if anything, they suggest that Cisco is still working from its well-thumbed playbook of ASIC-based switches in a network-centric world.

Moreover, with Tom Edsall, the lead ASIC architect on the Nexus and MDS switching lines, reportedly on board with Insieme, we can probably safely deduce that the ASIC will be front and center in whatever the spin-in effort delivers. So, if it’s an SDN architecture Insieme has been mandated to deliver, it will be one with a distributed control plane and absolutely no role for dumb, off-the-rack switches.

Two Possible Scenarios

With regard to the increasingly contested definition of SDN — look no further than the marketing messages of certain vendors or to the software-driven networking hijinks now occurring in the IETF — there’s also the possibility that what the Insieme pack are doing could be only incidentally connected to what many consider SDN.

With that in mind, I want to turn to some intriguing speculation that William Koss, now at Plexxi, has provided on what he believes Cisco’s latest spin-in venture might be building. In a post on his blog, Koss reviews Cisco’s switching history, much of it involving the three musketeers now reuniting at Insieme, He then explains why Cisco does spin-in ventures before he offers his assessment of what Insieme might be  trying to accomplish.

He offers two possible paths Insieme might take. The first path would involve Cisco attending to what Koss terms “unfinished business” (including Brocade) in the storage space. In this scenario, the Insieme team would build a successor switch to the Nexus line with storage-networking hooks. This switch would be intended as a crushing reply to Xsigo’s I/O Director, while simultaneously representing an attempt to limit further market encroachments by Arista Networks, currently well entrenched in low-latency application environments, and also to potentially inoculate against potential traction from SDN startups such as Nicira and Big Switch.

As for the second option, he envisions something proceeding along an “SDN OpenFlow strategy path.” In this scenario, Koss foresees a  new platform that functions as a “Nexus OS-to-OpenFlow arbitration box,” which he describes as analogous to a session border controller (SBC) between the two networks. This would give Cisco’s installed base to SDN-like capabilities while keeping them wrapped inside Cisco’s proprietary cocoon.

Surprise Not Likely

In my view, both paths described by Koss are plausible scenarios for Insieme.  My gut feeling is that the first is more likely. The second option is more software intensive, and it would seem to feature less of the ASIC and storage-networking expertise possessed by known members of the Insieme team. Perhaps Mario, Luca, and Prem will blaze an entirely different path and surprise us all, but Koss might be on the right track with his speculative musings.

As always, we shall see.

Cheriton Sees Opportunity in Infrastructure

When I wrote my first post on this blog, way back in 2006, I assumed that technology infrastructure largely was a spent force. I expected incremental enhancements, gradual advances, but I didn’t anticipate another major boom or a significant disruption of the established order in what once had been a vibrant technology space.

While the technology industry as a whole can suffer from blinkered, willful optimism, perhaps I was afflicted by a different condition entirely. I might have been too pessimistic, too gloomy, dispirited by the technology downturn of the early 2000s and the lack of a meaningful, sustained recovery in the years that immediately followed.

By the way, when I refer to technology, I’m not talking about social networking such as Facebook. I understand that there’s a lot of technology behind the scenes at Facebook, but the customer-facing “social” phenomenon leaves me cold. I never did see the point of Facebook from a user’s perspective, though I understood how it could serve as an unprecedented data-mining machine for advertisers.

Opportunity Renewed

Fortunately, though, I was wrong about the decline and fall of infrastructure. It took a while, but a new era of infrastructure has arisen, based on virtualization, orchestration, and automation. Technological possibilities that we could only dream about more than a decade ago are now possible. In the networking realm, software-defined networking (SDN) is enabling comparatively outmoded network infrastructure to catch up with compute and, to a lesser degree, storage infrastructure as the promise of an application-driven, programmable data center comes into clearer view.

Suddenly, at long last, there’s new opportunity in infrastructure.

You don’t have to take my word for it, either. There are people who’ve designed and developed industry-leading technologies who espouse the same opinion. Some of these people are billionaires, and they’re backed their convictions with substantial sums of money, investing in technologies and companies with clear mandates to remake IT infrastructure.

Outrageously Wealthy Canuck

One of those people is David Cheriton, a billionaire who wears many hats. He is Professor of Computer Science and Electrical Engineering at Stanford University, where he researches networking and distributed systems, and he also serves as a co-founder and chief scientist at Arista Networks. He’s also an investor in startup companies. Back in 1998, one early-stage company in which he invested, along with Arista co-founder Andy Bechtolsheim, was Google.  The duo made a similar early investment in VMware, so they’ve done okay.

Born in Vancouver, raised in Edmonton, Alberta, and ranked 37th on a Wikipedia list of “richest Canadians”** — Forbes ranks him 21st among outrageously wealthy Canucks  — Cheriton recently spoke about innovation and entrepreneurship at a Churchill Club event in Silicon Valley. The event was co-hosted and organized by the Hua Yuan Science and Technology Association and also featured Ken Xie, who founded NetScreen (acquired by Juniper Networks in 2004) and is now president and CEO of unified-threat-management/firewall vendor Fortinet, a company he also founded.

In addition to his apparent knack as an investor, Cheriton has considerable firsthand experience as an entrepreneur and an innovator. Before he and Bechtolsheim combined forces at Arista Networks,  they founded Granite Systems, a Gigabit-Ethernet switching concern that was acquired by Cisco in 1996 for about $220 million in stock, back when shares of Cisco were continuously on the rise.  Subsequently, after the Google investment, Bechtolsheim and Cheriton combined forces again to found Kealia, which specialized in server technology based on AMD’s Opteron microprocessor.  That company was acquired by Sun Microsystems in 2004, providing technology included in the Sun Fire X4500 storage product.

Room for Improvement

In 2005, Cheriton and Bechtolsheiim followed up with Arista, then called Arastra, and its 10-GbE switching technology, which brings us to the approximate present and back to something Cheriton said at the Churchill Club event late last month. Noting that people tend to become preoccupied with the latest developments in social networking and mobility, Cheriton expressed his enthusiasm for infrastructure, as an investment vehicle as well as an area in which he has an abiding technical interest. As quoted in a BusinessWeek article, Cheriton said: “I think there is an opportunity to go back and say, ‘Gee, I think there’s lot of room for improvement in the infrastructure.’ ”

Reinforcing that point, he noted that technology infrastructure today is predicated on ideas that are about 30 years old. The network was the place to start the infrastructure refurbishment, Cheriton believed, and Arista Networks grew from that conviction.

But Cheriton hasn’t stopped there. He also founded a company called Optumsoft, about which not much is known. On its website, Optumsoft is described as an early-stage startup company “taking distributed computing and distributed software development mainstream.” Quoting from the website:

Recent advancements in multi-core computing systems, coupled with the ever increasing functional and performance requirements of software has created an exciting market opportunity for addressing the programmatic and architectural issues involved in modern software development. Optumsoft is addressing this growing market with a novel technology approach that is transparent, scalable, and portable, resulting in significant improvement to the development and maintenance of distributed/parallel structured software systems. Early production usage by commercial clients has validated the technology and value proposition.

Last fall, an anonymous source suggested on Quora that what Optumsoft was building related to “how to structure object-oriented RPC in a way that makes it easy to build robust systems.  The technology behind Arista’s EOS is based on some of these ideas, as was software structure at a previous startup, Kealia.  The technology includes an IDL and a C++ runtime, similar to what you’d get using CORBA.”

Nebula and Tintri

On the investment side, Cheriton and Bechtolsheim have put money into Nebula, which has venture-capital backing from Kleiner Perkins Caulfield & Byers and Highland Capital Partners. Built on OpenStack, the Nebula Enterprise Cloud Appliance is designed to provision and configure flexible, scalable cloud-computing infrastructure. Although it doesn’t say so on the Nebula website, previous reports indicated that Arista’s networking technology is included in the Nebula appliance.

According to the BusinessWeek article,  Cheriton also has a stake in Tintri, co-founded by Kieran Harty and Mark Gritter. Harty was EVP of R&D at VMware for seven years, and Gritter was one of the first of Cheriton’s employees at Kealia. They’ve assembled a PhD-laden engineering team that has developed a virtual-machine-aware storage appliance designed for virtualized environments, which the company says have been underserved by older storage technology that apparently contributes to “VM stall.”

Another early-stage investment that Cheriton made was in Aster Data Systems, a purveyor of a massively parallel DBMS that runs on clustered commodity servers. Already a minority owner of Aster, Teradata bought the 89% of the company it didn’t own for $263 million last year.

Cheriton has made bets on infrastructure, and he’ll likely make others. It’s an encouraging sign for those of us who gravitate to that part of the industry.

(**No, I am not on the list, but thanks for asking.)

What Cisco’s SDN Spin-In Move Tells Us

Many of you have followed a series of posts I’ve written on rumblings that Cisco’s renowned engineering troika  of Mario Mazzola, Luca Cafiero, and Prem Jain would be reuniting to launch another venture.

Rumors last summer suggested that they might be incubating a networking company, perhaps in conjunction with a Valley venture capitalist. Subsequent rumors indicated that the Cisco engineering trio was building a switch as part of a startup company, maybe even as part of another Cisco spin-in company.

Spinning Back

During the last two weeks, rumors intensified and suggested that the threesome was building a data-center switch attuned to the requirements of cloud computing. It also became clear that this would indeed be another Cisco spin-in company. Now we learn, from a report in the New York Times, that the switch in question will feature software-defined networking (SDN), and that the principals behind the spin-in venture, called Insieme — it means “collection” or “assembly” in Italian — are involved in business negotiations with Cisco.

We don’t know much other than that, though. When asked by the New York Times about Insiemi, Cisco CEO John Chambers invoked a cone of silence, saying “we do not discuss our plans or internal investments.”

Well, hey, somebody’s been discussing this particular plan, if not the specific investment terms pertaining to it, because this has not been a particularly well-kept secret. Information has leaked out about it, some of it perhaps intentionally, for some time.

The negotiations relating to Insiemi will be about remuneration, deliverables, and timelines. Cisco will tie compensation to the realization of specific objectives. Now that it has come this far, getting reported in the New York Times, I doubt that it will go back into mothballs. It’s doubtless moving ahead.

Messages Imparted

So, what does that tell us?

Well, it tells us a few things. First, it indicates that Cisco felt it again needed the services of its spin-in wrecking crew, the team that came to Cisco initially in its first-ever acquisition, of Crescendo Communications back in 1993. That brought Cisco the Catalyst line of switches, which was no small prize, along with a talented roster of personnel that played a significant role in the company’s growth into an industry giant. After coming to Cisco, Crescendo’s engineering stars — they would be in Cisco’s Hall of Fame, if such a thing existed — then were involved in Cisco’s highest-profile spin-in efforts: Andiamo for storage networking, and Nuova, which developed data-center technology that found its way into Nexus switches and UCS blade servers.

That Cisco felt it needed the spin-in touch, especially involving this particular group of engineers, also tells us implicitly that Cisco didn’t feel the job could be done by the teams it already has working inside the company, including David Yen’s Server Access and Virtualization Technology Group (SAVTG). That’s interesting in and of itself, because Yen came over from Juniper Networks to effectively take the reins from Mazzola, Cafiero, and Jain, who then transitioned to “support Cisco in an advisory capacity.”  In that advisory capacity, which they assumed last spring, the trio reported to John Chambers directly, not to Yen’s bosses, senior vice presidents Padmasree Warrior and Pankaj Patel.

Potentials Risks As Well As Rewards

And now they’re back in the spin-in saddle, and you can make of that what you will. Rest assured, however, that much will be made of it on the Cisco campus . . . which brings us to the third thing that this move tells us.

These spin-in moves are not universally popular within Cisco Systems. While Cisco had entirely valid business and technology reasons for instituting its spin-in model, the practice has generated much internal discord and friction. Cisco employees not chosen to participate in the spin-in ventures have been known to become alienated and invidious. (I suppose “pissed off” might sum it up, but we usually aim for a higher order of decorum and eloquence around here.)

That was one of the reasons that I wondered, back in the spring of 2010, whether Cisco might have retired its spin-in move. While some external observers contend that Cisco overpays for its spin-in ventures, Cisco insiders who don’t get to travel on the spin-in express aren’t pleased about left behind on the station platform. In 2008, former Cisco executive Jayshree Ullal, who now serves as CEO of Arista Networks (more on which later), made the following comment to Forbes about the malignant consequences of spin-in ventures:

“Spin-ins are a creative model to accelerate innovation and bring in engineers you couldn’t normally recruit–and financial gains go to entrepreneurs, not venture capitalists,” says Jayshree Ullal, a 15-year Cisco veteran who built the 7000 then left last May as the Nuova people came back in. “But it’s a nightmare when the guy in the next cubicle is a multimillionaire and you aren’t, because you weren’t chosen.” She left Cisco for personal reasons, she says, adding that she had to deal with a lot of unhappy employees over the spin-in structure.

Cisco Takes SDN Threat Seriously

So, there will he happy employees and unhappy ones at Cisco, those who get tapped for the not-so-secret spin-in society and those who get left behind to maintain the workaday business. How troublesome that becomes, and whether it results a new stream of defections, remains to be seen.

One of those previous defections involved the aforementioned Jayshree Ullal, now CEO of Arista Networks. I intimated above that Arista figured into this story, and it does, as do Nicira Networks and the new breed of SDN purveyors.

If Cisco is betting big on a Mazzola-Cafiero-Jain spin-in venture related to SDN — and past performance tells us that these ventures are never small wagers — it tells that the Cisco takes very seriously the threat posed in the data center by Arista, which has staked its own SDN ground, and by SDN startups such as Nicira.

Cisco’s conception of SDN, as fashioned by its spin-in wrecking crew, might diverge in interesting ways from those others have put forward. Watch how terms are defined, and who does the defining, as the battle for hearts, minds, and wallets intensifies.

Arista’s Adaptable Approach to SDN

In an earlier post regarding Arista Networks’ march toward an IPO, I wrote that I would provide an overview of the company’s positioning on software-defined networking (SDN), which now follows. I think the subject is worth exploring given the buzz generated both by the IPO-bound Arista, with its notable market successes in high-frequency trading and other application environments requiring low-latency switching, and by SDN itself.

Last fall, when OpenFlow fever reached a boiling point, Arista Networks’ CEO Jayshree Ullal pointed out that it was just one mechanism of many that could be leveraged in the service of SDN. Among the others, she opined, were existing command-line interfaces (CLIs), Simple Network Management Protocol (SNMP), Extensible Messaging and Presence Protocol (XMPP), Network Configuration Protocol (NETCONF), OpenStack (with its Quantum project), as well as APIs in VMware’s vSphere virtualization software.

The Four Pillars

On the larger SDN canvas, Arista has propounded its “four pillars” of software-defined cloud networking (SDCN). You can read about Arista’s “four pillars” in a blog post written late last year by Ullal or in a white paper that can be found on Arista’s website. In both, the four pillars are identified as follows:

Pillar 1. Single Point of Management, which Arista believes can be achieved through layering atop the traditional control plane and data path of a cloud network and through coordinating configurations across multiple otherwise-independent switches. Arista says no fabric technology is required, and it says its CloudVision is up to the challenge.

Pillar 2: Single-image L2/3 Control Plane.  Here, Arista believes “standards-based L2/L3 IETF control-plane specifications plus OpenFlow options (without hype) can be a promising open augmentation for providing single image control planes in the future.”

Pillar 3. Multi-path Active-Active Data Path. The company prescribes scaling cloud networking across multiple chassis with Multi-Chassis Link Aggregation Group (MLAG) at L2 Equal Cost Multi-pathing (ECMP) at L3.

Pillar 4. Network-Wide Virtualization. Regarding this last pillar, the company says it makes sense to provision the entire network to handle any application seamlessly and so that the economics of virtualization can be properly leveraged “using controllers from VMware and their new paradigm for VMWare’s VXLANS or Open Virtualization Switching (OVS) controllers in the future.”

Best of Both Worlds?

As has been above (and in earlier posts), software-defined networking can be implemented in more than one fashion. Some networking vendors — typically industry mainstays with large installed bases of customers and firmly established business models predicated on hardware ASICs, proprietary protocols, and relatively high margins — will opt for an SDN vision that features a distributed control plane. Not for them the dramatic shift to logically centralized server-based controllers, designed to subsume networking within a computing paradigm. To the traditional networking vendor, that road looks treacherous and leads to a diminution of the status and margins associated with the beloved switch.

As neither a raw SDN startup nor a legacy networking company, Arista takes a flexible position on how SDNs can be realized. The company says customers can implement SDNs by using controllers or by using distributed-control mechanisms. Ideally, according to Arista, both means should be employed for comprehensive SDN capabilities. A presentation available online explains the company’s position on this best-of-both-worlds approach to the control plane.

Finally, it probably comes as no surprise that Arista prescribes its own Linux-based Extensible Operating System (EOS) as the appropriate software foundation for its four pillars and for cloud networking in general. It also believes that “good old fashioned Ethernet scaling from 10 gigabits to 40 gigabits to 100 Gigabits and even terabits with well-defined standards and protocols for L2/L3 is the optimal approach.”

In view of the media blitz undertaken by Arista founders Andreas Bechtolsheim and David Cheriton late last year, we should expect the company’s next generation of switches to deliver as much bandwidth as Ethernet and merchant silicon will allow.

Update on Arista’s Road to IPO

From the search terms for this blog, I know many of you have a strong interest in learning about Arista Networks’ plans for an IPO.

I intended to touch on the company’s IPO plans within a larger post on its strategy for software-defined networking (SDN), but I’ve decided that the two threads should be addressed separately.

So, where does Arista Networks stand with its IPO plans? I believe the company is still very much on track for an IPO, though forecasting a specific date for such an event is not something I’ll do here. I would say that an IPO remains Arista’s preferred exit strategy. I don’t see the company selling to Cisco or to anybody else before a public offering. Sources say that Arista already has been approached by potential acquirers, but that it wasn’t interested in pursuing that option.

Looking for CFO

In that context, remember that Arista is not a VC-funded company. It has been financed by its principals, and it controls its own destiny. As such, Arista is not under external pressure to consider or reconsider buyout propositions.

At the moment, Arista does not have a chief financial officer (CFO). Last fall, at the same time the company announced the addition of two independent board members, Steffan Tomlinson joined Arista as its chief financial officer.  He left the company after just a few months, however, and is now CFO at network-security player Palo Alto Networks. Previously, Tomlinson served as CFO at Aruba Networks when it went public in 2007.

Nobody is saying much about the circumstances of Tomlinson’s departure from Arista. Sources say that the parting of the ways had nothing to do with Arista’s financial performance. As noted above, all reports suggest the company remains on track for an IPO. Before long, we should see an announcement regarding the hiring of a new CFO.

All of you who have been seeking an update on Arista’s IPO plans — and I know there are many of you — now have one.

Exploring the Symbiosis Between Merchant Silicon and Software-Defined Networking

In a recent post at EtherealMind.com, Greg Ferro examined possible implications associated with the impending dominance of merchant silicon in the networking industry.

Early in his post, Ferro reproduces a Broadcom graphic illustrating that the major switch vendors all employ Broadcom’s Trident chipset family in their gear. Vendors represented on the graphic include Cisco, Juniper, Dell, Arista, HP, IBM (BNT), and Alcatel-Lucent.

Abyss Awaits

Custom switching ASICs haven’t gone the way of eight-track cartridges just yet, but the technology industry’s grim reaper is quickening his loping stride and approaching at a baleful gallop, scythe at the ready. Interrelated economic and technological factors have conspired, as they will, to put the custom ASIC on a terminal path.

There’s a chicken-and-egg debate as to whether economics occasioned and hastened this technological change or whether the causation was reversed, but, either way, the result will be the same. At some point, for switching purposes, it will become counterproductive and economically untenable to continue to design, develop, and incorporate custom ASICs into shipping products.

What’s more, the custom ASIC’s trip to the boneyard will be expedited, at least in part, by the symbiotic relationship that has developed between merchant silicon and software-defined networking (SDN).

Difficult Adjustment for Some

Commercially, of course, merchant silicon preceded SDNs by a number of years. Recently, however, the two have converged dynamically, so much so that, as Ferro acknowledges, future differentiation in networking will derive overwhelmingly from advances in software rather than from those in hardware. Vendors will offer identical hardware. They will compete on the basis of their software, including the applications and, yes, the management capabilities they bring to market.

For companies that have marketed and sold their products primarily on the basis of hardware speeds and feeds and associated features and benefits, the adjustment will be difficult.  The bigger the ship, the harder it will be to turn.

There are some caveats, of course. While seemingly inevitable, this narrative could take some time to play out.  Although the commercial success of merchant silicon was not contingent on the rise of software-defined networks, the continued ascent of the latter will accelerate and cement the dominance of the former. To the extent that the SDN movement — perhaps torn between OpenFlow and other mechanisms and protocols — fragments or is otherwise slowed in its progress, the life of the custom ASIC might be prolonged.

Timing the Enterprise Transition

Similarly, even if we presuppose that SDN technology and its ecosystem progress smoothly and steadily, SDN is likely to gain meaningful traction first with service providers and only later with enterprises. That said, the line demarcating enterprises and service providers will move and blur as applications and infrastructure migrate, in whole or in part, to the cloud. It’s anybody’s guess as to when and exactly how that transition will transform the enterprise-networking market, but we can see the outlines of change on the horizon.

Nothing ever plays out in the real world exactly as it does on paper, so I expect complications to spoil the prescience of the foregoing forecast.

Still, I know one thing for sure: As the SDN phenomenon eventually takes hold, the role of the switch will change, and that means the design of the switch will change. If the switch is destined to become a dumbed-down data-forwarding box, it doesn’t need a custom ASIC. Merchant silicon is more than up to that task.

Vendors Cite Other Paths to SDNs

Jim Duffy at NetworkWorld wrote an article earlier this month on protocol and API alternatives to OpenFlow as software-defined network (SDN) enablers.

It’s true, of course, that OpenFlow is a just one mechanism among many that can be used to bring SDNs to fruition. Many of the alternatives cited by Duffy, who quoted vendors and analysts in his piece, have been around longer than OpenFlow. Accordingly, they have been implemented by network-equipment vendors and deployed in commercial networks by enterprises and service providers. So, you know, they have that going for them, and it is not a paltry consideration.

No Panacea

Among the alternatives to OpenFlow mentioned in that article and in a sidebar companion piece were command-line interfaces (CLIs), Simple Network Management Protocol (SNMP), Extensible Messaging and Presence Protocol (XMPP), Network Configuration Protocol (NETCONF), OpenStack, and virtualization APIs in offerings such as VMware’s vSphere.

I understand that different applications require different approaches to SDNs, and I’m staunchly in the reality-based camp that acknowledges OpenFlow is not a networking panacea. As I’ve noted previously on more than one occasion, the Open Networking Foundation (ONF), steered by a board of directors representing leading cloud-service operators, has designs on OpenFlow that will make it — at least initially — more valuable to so-called “web-scale” service providers than to enterprises. Purveyors of switches also get short shrift from the ONF.

So, no, OpenFlow isn’t all things to all SDNs, but neither are the alternative APIs and protocols cited in the NetworkWorld articles. Reality, even in the realm of SDNs, has more than one manifestation.

OpenFlow Fills the Void

For the most part, however, the alternatives to OpenFlow have legacies on their side. They’re tried and tested, and they have delivered value in real-world deployments. Then again, those legacies are double-edged swords. One might well ask — and I suppose I’m doing so here — if those foregoing alternatives to OpenFlow were so proficient at facilitating SDNs, then why is OpenFlow the recipient of such perceived need and demonstrable momentum today?

Those pre-existing protocols did many things right, but it’s obvious that they were not perceived to address at least some of the requirements and application scenarios where OpenFlow offers such compelling technological and market potential. The market abhors a vacuum, and OpenFlow has been called forth to fill a need.

Old-School Swagger

Relative to OpenFlow, CLIs seem a particularly poor choice for the realization of SDN-type programmability. In the NetworkWorld companion piece, Arista Networks CEO Jayshree Ullal is quoted as follows:

“There’s more than one way to be open. And there’s more than one way to scale. CLIs may not be a programmable interface with a (user interface) we are used to; but it’s the way real men build real networks today.”

Notwithstanding Ullal’s blatant appeal to engineering machismo, evoking a networking reprise of Saturday Night Live’s old “¿Quien Es Mas Macho?” sketches, I doubt that even the most red-blooded networking professionals would opt for CLIs as a means of SDN fulfillment. In qualifying her statement, Ullal seems to concede as much.

Rubbishing Pretensions

Over at the Big Switch Networks, Omar Baldonado isn’t shy about rubbishing CLI pretensions to SDN superstardom. Granted, Big Switch Networks isn’t a disinterested party when it comes to OpenFlow, but neither are any of the other networking vendors, whether happily ensconced on the OpenFlow bandwagon or throwing rotten tomatoes at it from alleys along the parade route.

Baldonado probably does more than is necessary to hammer home his case against CLIs for SDNs, but I think the following excerpt, in which he stresses that CLIs were and are meant to be used to configure network devices, summarizes his argument pithily:

“The CLI was not designed for layers of software above it to program the network. I think we’d all agree that if we were to put our software hats on and design such a programming API, we would not come up with a CLI!”

That seems about right, and I don’t think we need belabor the point further.

Other Options

What about some of the other OpenFlow alternatives, though? As I said, I think OpenFlow is well crafted for the purposes the high priests of the Open Networking Foundation have in store for it, but enterprises are a different matter, at least for the foreseeable future (which is perhaps more foreseeable by some than by others, your humble scribe included).

In a subsequent post — I’d like to say it will be my next one, but something else, doubtless shiny and superficially appealing, will probably intrude to capture my attentions — I’ll be looking at OpenStack’s applicability in an SDN context.