Category Archives: OpenStack

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.)

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.

Why Many Networking Professionals Will Resist Software-Defined Networking

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

It just might not happen as quickly as some expect.

Shape of Networking to Come

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

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

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

Winning Hearts and Minds

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

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

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

Networking’s Cultural Artifacts

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

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

Getting the Network “Out of the Way”

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

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

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

Vendors in No Hurry

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

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

Deferred Gratification

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

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

Peeling the Nicira Onion

Nicira emerged from pseudo-stealth yesterday, drawing plenty of press coverage in the process. “Network virtualization” is the concise, two-word marketing message the company delivered, on its own and through the analysts and journalists who greeted its long-awaited official arrival on the networking scene.

The company’s website opened for business this week replete with a new look and an abundance of new content. Even so, the content seemed short on hard substance, and those covering the company’s launch interpreted Nicira’s message in a surprisingly varied manner, somewhat like blind men groping different parts of an elephant. (Onion in the title, now an elephant; I’m already mixing flora and fauna metaphors.)

VMware of Networking Ambiguity

Many made the point that Nicira aims to become the “VMware of networking.” Interestingly, Big Switch Networks has aspirations to wear that crown, asserting on its website that “networking needs a VMware.” The theme also has been featured in posts on Network Heresy, Nicira CTO Martin Casado’s blog. He and his colleagues have written alternately that networking both doesn’t and does need a VMware. Confused? That’s okay. Many are in the same boat . . . or onion field, as the case may be.

The point Casado and company were trying to make is that network virtualization, while seemingly overdue and necessary, is not the same as server virtualization. As stated in the first in that series of posts at Network Heresy:

“Virtualized servers are effectively self contained in that they are only very loosely coupled to one another (there are a few exceptions to this rule, but even then, the groupings with direct relationships are small). As a result, the virtualization logic doesn’t need to deal with the complexity of state sharing between many entities.

A virtualized network solution, on the other hand, has to deal with all ports on the network, most of which can be assumed to have a direct relationship (the ability to communicate via some service model). Therefore, the virtual networking logic not only has to deal with N instances of N state (assuming every port wants to talk to every other port), but it has to ensure that state is consistent (or at least safely inconsistent) along all of the elements on the path of a packet. Inconsistent state can result in packet loss (not a huge deal) or much worse, delivery of the packet to the wrong location.”

In Context of SDN Universe

That issue aside, many writers covering the Nicira launch presented information about the company and its overall value proposition consistently. Some articles were more detailed than others. One at MIT’s Technology Review provided good historical background on how Casado first got involved with the challenge of network virtualization and how Nicira was formed to deliver a solution.

Jim Duffy provided a solid piece touching on the company’s origins, its venture-capital investors, and its early adopters and the problems Nicira is solving for them. He also touched on where Nicira appears to fit within the context of the wider SDN universe, which includes established vendors such as Cisco Systems, HP, and Juniper Networks, as well as startup such as Big Switch Networks, Embrane, and Contextream.

In that respect, it’s interesting to note what Embrane co-founder and President Dante Malagrino told Duffy:

 “The introduction of another network virtualization product is further validation that the network is in dire need of increased agility and programmability to support the emergence of a more dynamic data center and the cloud.”

“Traditional networking vendors aren’t delivering this, which is why companies like Nicira and Embrane are so attractive to service providers and enterprises. Embrane’s network services platform can be implemented within the re-architected approach proposed by Nicira, or in traditional network architectures. At the same time, products that address Layer 2-3 and platforms that address Layer 4-7 are not interchangeable and it’s important for the industry to understand the differences as the network catches up to the cloud.”

What’s Nicira Selling?

All of which brings us back to what Nicira actually is delivering to market. The company’s website offers videos, white papers, and product data sheets addressing the Nicira Network Virtualization Platform (NVP) and its Distributed Network Virtualization Infrastructure (DNVI), but I found the most helpful and straightforward explanations, strangely enough, on the Frequently Asked Questions (FAQ) page.

This is an instance of a FAQ page that actually does provide answers to common questions. We learn, for example, that the key components of the Nicira Network Virtualization Platform (NVP) are the following:

- The Controller cluster, a distributed control system

- The Management software, an operations console

- The RESTful API that integrates into a range of Cloud Management Systems (CMS), including a Quantum plug-in for OpenStack.

Those components, which constitute the NVP software suite, are what Nicira sells, albeit in a service-oriented monthly subscription model that scales per virtual network port.

Open vSwitch, Minor Role for OpenFlow 

We then learn that the NVP communicates with the physical network indirectly, through Open vSwitch. Ivan Pepelnjak (I always worry that I’ll misspell his name, but not the Ivan part) provides further insight into how Nicira leverages Open vSwitch. As Nicira notes, the NVP Controller communicates directly with Open vSwitch (OVS), which is deployed in server hypervisors. The server hypervisor then connects to the physical network and end hosts connect to the vswitch. As a result, NVP does not talk directly to the physical network.

As for OpenFlow, its role is relatively minor. As Nicira explains: “OpenFlow is the communications protocol between the controller and OVS instances at the edge of the network. It does not directly communicate with the physical network elements and is thus not subject to scaling challenges of hardware-dependent, hop-by-hop OpenFlow solutions.”

Questions About L4-7 Network Services

Nicira sees its Network Virtualization Platform delivering value in a number of different contexts, including the provision of hardware-independent virtual networks; virtual-machine mobility across subnet boundaries (while maintaining L2 adjacency); edge-enforced, dynamic QoS and security policies (filters, tagging, policy routing, etc.) bound to virtual ports; centralized system-wide visibility & monitoring; address space isolation (L2 & L3); and Layer 4-7 services.

Now that last capability provokes some questions that cannot be answered in the FAQ.

Nicira says its NVP can integrate with third-party Layer 3-7 services, but it also says services can be created by Nicira or its customers.  Notwithstanding Embrane’s perfectly valid contention that its network-services platform can be delivered in conjunction with Nicira’s architectural model, there is a distinct possibility Nicira might have other plans.

This is something that bears watching, not only by Embrane but also by longstanding Layer 4-7 service-delivery vendors such as F5 Networks. At this point, I don’t pretend to know how far or how fast Nicira’s ambitions extend, but I would imagine they’ll be demarcated, at least partly, by the needs and requirements of its customers.

Nicira’s Early Niche

Speaking of which, Nicira has an impressive list of early adopters, including AT&T, eBay, Fidelity Investments, Rackspace, Deutsche Telekom, and Japan’s NTT. You’ll notice a commonality in the customer profiles, even if their application scenarios vary. Basically, these all are public cloud providers, of one sort or another, and they have what are called “web-scale” data centers.

While Nicira and Big Switch Networks both are purveyors of “network virtualization”  and controller platforms — and both proclaim that networking needs a VMware — they’re aiming at different markets. Big Switch is focusing on the enterprise and the private cloud, whereas Nicira is aiming for large public cloud-service providers or big enterprises that provide public-cloud services (such as Fidelity).

Nicira has taken care in selecting its market. An earlier post on Casado’s blog suggests that he and Nicira believe that OpenFl0w-based SDNs might be a solution in search of a problem already being addressed satisfactorily within many enterprises. I’m sure the team at Big Switch would argue otherwise.

At the same time, Nicira probably has conceded that it won’t be patronized by Open Networking Foundation (ONF) board members such as Google, Facebook, and Microsoft, each of which is likely to roll its own network-virtualization systems, controller platforms, and SDN applications. These companies not only have the resources to do so, but they also have a business imperative that drives them in that direction. This is especially true for Google, which views its data-center infrastructure as a competitive differentiator.

Telcos Viable Targets

That said, I can see at least a couple ONF board members that might find Nicira’s pitch compelling. In fact, one, Deutsche Telekom, already is on board, at least in part, and perhaps Verizon will come along later. The telcos are more likely than a Google to need assistance with SDN rollouts.

One last night on Nicira before I end this already-prolix post. In the feature article at Technology Review, Casado says it’s difficult for Nicira to impress a layperson with its technology, that “people do struggle to understand it.” That’s undoubtedly true, but Nicira needs to keep trying to refine its message, for its own sake as well as for those of prospective customers and other stakeholders.

That said, the company is stocked with impressive minds, on both the business and technology sides of the house, and I’m confident it will get there.

Reflecting on the Big Acquisition Cisco Didn’t Make

It has been nearly eight years since EMC acquired VMware. The acquisition announcement went over the newswires on December 15, 2003. EMC paid approximately $635 million for VMware, and Joe Tucci, EMC’s president and CEO, had this to say about the deal:

“Customers want help simplifying the management of their IT infrastructures. This is more than a storage challenge. Until now, server and storage virtualization have existed as disparate entities. Today, EMC is accelerating the convergence of these two worlds .“

“We’ve been working with the talented VMware team for some time now, and we understand why they are considered one of the hottest technology companies anywhere. With the resources and commitment of EMC behind VMware’s leading server virtualization technologies and the partnerships that help bring these technologies to market, we look forward to a prosperous future together.”

Virtualization Goldmine

Oh, the future was prosperous . . . and then some. It’s a deal that worked out hugely in EMC’s favor. Even though the storage behemoth has spun out VMware in the interim, allowing it to go public, EMC still retains more than 80 percent ownership of its virtualization goldmine.

Consider that EMC paid just $635 million in 2003 to buy the server-virtualization market leader. VMware’s current market capitalization is more than $38 billion. That means EMC’s stake in VMware is worth more than $30 billion, not including the gains it reaped when it took VMware public. I don’t think it’s hyperbolic to suggest that EMC’s purchase of VMware will be remembered as Tucci’s defining moment as EMC chieftain.

Now, let’s consider another vendor that had an opportunity to acquire VMware back in 2003.

Massive Market Cap, Industry Dominance

A few years earlier, at the pinnacle of the dot-com boom in March 2000, Cisco was the most valuable company in the world, sporting a market capitalization of more than US$500 billion.  It was a networking colossus that bestrode the globe, dominating its realm of the industry as much as any other technology company during any other period. (Its only peers in that regard were IBM in the mainframe era and Microsoft and Intel in the client-server epoch.)

Although Juniper Networks brought its first router to market in the fall of 1998 and began to challenge Cisco for routing patronage at many carriers early in the first decade of the new millennium, Cisco remained relatively unscathed in enterprise networking, where its Catalyst switches grew into a multibillion-dollar franchise after it saw off competitive challenges in the late 90s from companies such as 3Com, Cabletron, Nortel, and others.

As was its wont since its first acquisition, involving Crescendo Communications in 1993, Cisco remained an active buyer of technology companies. It bought companies to inorganically fortify its technological innovation, and to preclude competitors from gaining footholds among its expanding installed base of customers.

Non-Buyer’s Remorse?

It’s true that the post-boom dot-com bust cooled Cisco’s acquisitive ardor. Nonetheless, the networking giant made nine acquisitions from May 2002 through to the end of 2003. The companies Cisco acquired in that span included Hammerhead Networks, Navarro Networks, AYR Networks, Andiamo Systems, Psionic Software, Okena, SignalWorks, Linksys, and Latitude Communications.

The biggest acquisition in that period involved spin-in play Andiamo Systems, which provided the technological foundation for Cisco’s subsequent push to dominate storage networking. Cisco was at risk of paying as much as $2.5 billion for Andiamo, but the actual price tag for that convoluted spin-in transaction was closer to $750 million by the time it finally closed in 2004. The next-biggest Cisco acquisition during that period involved home-networking vendor Linksys, for which Cisco paid about $500 million.

Cisco announced the acquisitions of Hammerhead Networks and Navarro Networks in a single press release. Hammerhead, for which Cisco exchanged common stock valued at up to $173 million, developed software that accelerated the delivery of IP-based billing, security, and QoS; the company was folded into the Cable Business Unit in Cisco’s Network Edge and Aggregation Routing Group. Navarro Networks, for which Cisco exchanged common stock valued at up to $85 million, designed ASIC components for Ethernet switching.

To acquire AYR Networks, a vendor of “high-performance distributed networking services and highly scalable routing software technologies,” Cisco parted with about $113 million in common stock. AYR’s technology was intended to augment Cisco’s IOS software.

Andiamo Factor

Although the facts probably are familiar to many readers, Cisco’s acquisition of Andiamo was noteworthy for several reasons.  It was a spin-in acquisition, in which Cisco funded the company to go off and develop technology on its own, only later to be brought back in-house through acquisition. Andiamo was led by its CEO Buck Gee, and it included a core group of engineers who also were at Cresendo Communications.  The concept and execution of the spin-in move at Cisco was highly controversial within the company, seen as operationally and strategically innovative by many senior executives even though others claimed it engendered envy, invidious, and resentment among rank-and-file employees.

No matter, Andiamo was meant to provide market leadership for Cisco in the IP-based storage networking and to give Cisco a means of battering Brocade in Fibre Channel. That plan hasn’t come to fruition, with Brocade still leading in a tenacious Fibre Channel market and Cisco banking on Fibre Channel over Ethernet (FCoE) to go from the edge to the core. (The future of storage networking, including the often entertaining Fiber Channel-versus-FCoE debates, are another matter, and not within the purview of this post.)

While we’re on the topic of Andiamo, its former engineers continue to make news. Just this week, former Andiamo engineers Dante Malagrinò and Marco Di Benedetto officially launched Embrane, a company that is committed to delivering a platform for virtualized L4-7 network services at large cloud service providers. Those two gentlemen also were involved in Cisco last big spin-in move, Nuova Systems, which provided the foundation for Cisco’s Unified Computing Systems (UCS).

As for Cisco’s post-Andiamo acquisition announcements in 2002, Okena and Psionic both were involved in intrusion-detection technology. Of the two, Okena represented the larger transaction, valued at about $154 million in stock.

Interestingly, not much is available publicly these days regarding Cisco’s announced acquisition of SignalWorks in March of 2003. If you visit the CrunchBase profile for SignalWorks and click on a link that is supposed to take you to a Cisco press release announcing the deal, you’ll get a “Not Found” message. A search of the Cisco website turns up two press releases — relating to financial results in Cisco’s third and fourth quarters of fiscal year 2003, respectively — that obliquely mention the SignalWorks acquisition. The purchase price of the IP-audio company was about $16 million. CNet also covered the acquisition when it first came to light.

Other Strategic Priorities

Cisco’s last announced acquisitions in that timeframe involved home-networking player Linksys, part of Cisco’s ultimately underachieving bid to become a major player in the consumer space, and web-conferencing vendor Latitude Communications.

And now we get the crux of this post. Cisco announced a number of acquisitions in 2002 and 2003, but it was one they didn’t make that reverberates to this day. It was a watershed acquisition, a strategic masterstroke, but it was made by EMC, not by Cisco. As I said, the implications resound through to this day and probably will continue to ramify for years to come.

Some might contend that Cisco perhaps didn’t grasp the long-term significance of virtualization. Apparently, though, some at Cisco were clamoring for the company to buy VMware.  The missed opportunity wasn’t attributable to Cisco failing to see the importance of virtualization — some at Cisco had the prescience to see where the technology would lead — but because an acquisition of VMware wasn’t considered as high a priority as the spin-in of Andiamo for storage networking and the acquisition of Linksys for home networking.

Cisco placed its bets elsewhere, perhaps thinking that it had more time to develop a coherent and comprehensive strategy for virtualization. Then EMC made its move.

Missed the Big Chance

To this day, in my view, Cisco is paying an exorbitant opportunity cost for failing to take VMware off the market, leaving it for EMC and ultimately allowing the storage leader, yeas later, to gain the upper hand in the Virtual Computing Environment (VCE) Company joint venture that delivers UCS-encompassing VBlocks. There’s a rich irony there, too, when one considers that Cisco’s UCS contribution to the VBlock package is represented by technology derived from spin-in Nuova.

But forget about VCE and VBlocks. What about the bigger picture? Although Cisco likes to talk itself up as a leader in virtualization, it’s not nearly as prominent or dominant as it might have been. Is there anybody who would argue that Cisco, if it had acquired and then integrated and assimilated VMware as half as well as it digested Crescendo, wouldn’t have absolutely thrashed all comers in converged data-center infrastructure and cloud infrastructure?

Cisco belatedly recognized its error of omission, but it was too late. By 2009, EMC was not interested in selling its majority stake in VMware to Cisco, and Cisco was in no position to try to obtain it through an acquisition of EMC. In that regard, Cisco’s position has only worsened.

Although EMC’s ownership stake in VMware amounts to about 80 percent (or perhaps even just north of that amount), its has 98 percent of the voting shares in the company, which effectively means EMC steers the ship, regardless of public pronouncements VMware executives might issue regarding their firm being an autonomous corporate entity.

Keeping Cisco Interested but Contained 

Conversely, Cisco owns approximately five percent of VMware’s Class A shares, but none of its Class B shares, and it held just one percent of voting power as of March 2011.  As of that same date, EMC owned all of VMware’s 330,000,000 Class B Shares and 33,066,050 of its 118,462,369 shares of Class A common shares. Cisco has a stake in VMware, but it’s a small one and it has it at the pleasure of EMC, whose objective is to keep Cisco sufficiently interested so as not to pursue other strategic options in data-center virtualization and cloud infrastructure.

The EMC gambit has worked, up to the point. But Cisco, which missed its big chance  in 2003, has been trying ever since then to reassert its authority. Nuova, and all that flowed from it, was Cisco’s first attempt to regain lost ground, and now it is partnering, to varying degrees, with VMware and EMC competitors such as NetApp, Citrix, and Microsoft. It also has gotten involved involved with OpenStack and the oVirt Project in a bid to hedge its virtualization bets.

Yes, some of those moves are indicative of coopetition, and Cisco retains its occasionally strained VCE joint venture with EMC and VMware, but Cisco clearly is playing for time, looking for a way to redefine the rules of the game.

What Cisco is trying to do is break an impasse of its own making, a result of strategic choices it made nearly a decade ago.

Exploring OpenStack’s SDN Connections

Pursuant to my last post, I will now examine the role of OpenStack in the context of software-defined networking (SDN). As you will recall, it was one of the alternative SDN enabling technologies mentioned in a recent article and sidebar at Network World.

First, though, I want to note that, contrary to the concerns I expressed in the preceding post, I wasn’t distracted by a shiny object before getting around to writing this installment. I feared I would be, but my powers of concentration and focus held sway. It’s a small victory, but I’ll take it.

Road to Quantum

Now, on to OpenStack, which I’ve written about previously, though admittedly not in the context of SDNs. As for how networking evolved into a distinct facet of OpenStack, Martin Casado, chief technology officer at Nicira, offers a thorough narrative at the Open vSwitch website.

Casado begins by explaining that OpenStack is a “cloud management system (CMS) that orchestrates compute, storage, and networking to provide a platform for building on demand services such as IaaS.” He notes that OpenStack’s primary components were OpenStack Compute (Nova), Open Stack Storage (Swift), and OpenStack Image Services (Glance), and he also provides an overview of their respective roles.

Then he asks, as one might, what about networking? At this point, I will quote directly from his Open vSwitch post:

“Noticeably absent from the list of major subcomponents within OpenStack is networking. The historical reason for this is that networking was originally designed as a part of Nova which supported two networking models:

● Flat Networking – A single global network for workloads hosted in an OpenStack Cloud.

●VLAN based Networking – A network segmentation mechanism that leverages existing VLAN technology to provide each OpenStack tenant, its own private network.

While these models have worked well thus far, and are very reasonable approaches to networking in the cloud, not treating networking as a first class citizen (like compute and storage) reduces the modularity of the architecture.”

As a result of Nova’s networking shortcomings, which Casado enumerates in detail,  Quantum, a standalone networking component, was developed.

Network Connectivity as a Service

The OpenStack wiki defines Quantum as “an incubated OpenStack project to provide “network connectivity as a service” between interface devices (e.g., vNICs) managed by other Openstack services (e.g., nova).” On that same wiki, Quantum is touted as being able to support advanced network topologies beyond the scope of  Nova’s FlatManager or VLanManager; as enabling anyone to “build advanced network services (open and closed source) that plug into Openstack networks”; and as enabling new plugins (open and closed source) that introduce advanced network capabilities.

Okay, but how does it relate specifically to SDNs? That’s a good question, and James Urquhart has provided a clear and compelling answer, which later was summarized succinctly by Stuart Miniman at Wikibon. What Urquhart wrote actually connects the dots between OpenStack’s Quantum and OpenFlow-enabled SDNs. Here’s a salient excerpt:

“. . . . how does OpenFlow relate to Quantum? It’s simple, really. Quantum is an application-level abstraction of networking that relies on plug-in implementations to map the abstraction(s) to reality. OpenFlow-based networking systems are one possible mechanism to be used by a plug-in to deliver a Quantum abstraction.

OpenFlow itself does not provide a network abstraction; that takes software that implements the protocol. Quantum itself does not talk to switches directly; that takes additional software (in the form of a plug-in). Those software components may be one and the same, or a Quantum plug-in might talk to an OpenFlow-based controller software via an API (like the Open vSwitch API).”

Cisco’s Contribution

So, that addresses the complementary functionality of OpenStack’s Quantum and OpenFlow, but, as Urquhart noted, OpenFlow is just one mechanism that can be used by a plug-in to deliver a Quantum abstraction. Further to that point, bear in mind that Quantum, as recounted on the OpenStack wiki, can be used  to “build advanced network services (open and closed source) that plug into OpenStack networks” and to facilitate new plugins that introduce advanced network capabilities.

Consequently, when it comes to using OpenStack in SDNs, OpenFlow isn’t the only complementary option available. In fact, Cisco is in on the action, using Quantum to “develop API extensions and plug-in drivers for creating virtual network segments on top of Cisco NX-OS and UCS.”

Cisco portrays itself as a major contributor to OpenStack’s Quantum, and the evidence seems to support that assertion. Cisco also has indicated qualified support for OpenFlow, so there’s a chance OpenStack and OpenFlow might intersect on a Cisco roadmap. That said, Cisco’s initial OpenStack-related networking forays relate to its proprietary technologies and existing products.

Citrix, Nicira, Rackspace . . . and Midokura

Other companies have made contributions to OpenStack’s Quantum, too. In a post at Network World, Alan Shimel of The CISO Group cites the involvement of Nicira, Cisco, Citrix, Midokura, and Rackspace. From what Nicira’s Casado has written and said publicly, we know that OpenFlow is in the mix there. It seems to be in the picture at Rackspace, too. Citrix has posted blog posts about Quantum, including this one, but I’m not sure where they’re going with it, though XenServer, Open vSwitch, and, yes, OpenFlow are likely to be involved.

Finally, we have Midokura, a Japanese company that has a relatively low profile, at least on this side of the Pacific Ocean. According to its website, it was established early in 2010, and it had just 12 employees in the end of April 2011.

If my currency-conversion calculations (from Japanese yen) are correct, Midokura also had about $1.5 million in capital as of that date. Earlier that same month, the company announced seed funding of about $1.3 million. Investors were Bit-Isle, a Japanese data-center company; NTT Investment Partners, an investment vehicle of  Nippon Telegraph & Telephone Corp. (NTT); 1st Holdings, a Japanese ISV that specializes in tools and middleware; and various individual investors, including Allen Miner, CEO of SunBridge Corporation.

On its website, Midokura provides an overview of its MidoNet network-virtualization platform, which is billed as providing a solution to the problem of inflexible and expensive large-scale physical networks that tend to lock service providers into a single vendor.

Virtual Network Model in Cloud Stack

In an article published  at TechCrunch this spring, at about the time Midokura announced its seed round, the company claimed to be the only one to have “a true virtual network model” in a cloud stack. The TechCrunch piece also said the MidoNet platform could be integrated “into existing products, as a standalone solution, via a NaaS model, or through Midostack, Midokura’s own cloud (IaaS/EC2) distribution of OpenStack (basically the delivery mechanism for Midonet and the company’s main product).”

Although the company was accepting beta customers last spring, it hasn’t updated its corporate blog since December 2010. Its “Events” page, however, shows signs of life, with Midokura indicating that it will be attending or participating in the grand opening of Rackspace’s San Francisco office on December 1.

Perhaps we’ll get an update then on Midokura’s progress.

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.