F5’s Look Ahead

I’ve always admired how F5 Networks built its business. Against what seemed heavy odds at the time, F5 took the fight to Cisco Systems and established market leadership in load balancing, which subsequently morphed into market leadership in application delivery controllers (ADC).

F5 now talks about its “Intelligent Services Platform,” which “connects any user, anywhere, from any device to the best application resources, independent of infrastructure.”

To be sure, as various permutations of cloud computing take hold and mobile devices proliferate, the market is shifting, and F5 is attempting to move with it. To get a feel for how F5 sees the world, where it sees things going, and how it intends to meet new challenges, you might want to have a look at a 211-slide (yes, that many) presentation that company executives made to analysts and investors yesterday. 

By its nature, the presentation is mostly high-level stuff, but it offers interesting nuggets on markets, products, technologies, and partnerships.  

Advertisement

Cisco Puts ACE in the Hole (or Maybe Not)

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

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

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

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

Bigger Picture

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

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

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

A Matter of Focus and Priority

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

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

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

Understanding Cisco’s Relationship to SDN Market

Analysts and observers have variously applauded or denounced Cisco for its network-Cisco ONE programmability pronouncements last week.  Some pilloried the company for being tentative in its approach to SDN, contrasting the industry giant’s perceived reticence with its aggressive pursuit of previous emerging technology markets such as IP PBX, videoconferencing, and converged infrastructure (servers).

Conversely, others have lauded Cisco’s approach to SDN as far more aggressive than its lackluster reply to challenges in market segments such as application-delivery controllers (ADCs) and WAN optimization, where F5 and Riverbed, respectively, demonstrated how a tightly focused strategy and expertise above the network layer could pay off against Cisco.

Different This TIme

But I think they’ve missed a very important point about Cisco’s relationship to the emerging SDN market.  Analogies and comparisons should be handled with care. Close inspection reveals that SDN and the applications it enables represent a completely different proposition from the markets mentioned above.

Let’s break this down by examining Cisco’s aggressive pursuit of IP-based voice and video. It’s not a mystery as to why Cisco chose to charge headlong into those markets. They were opportunities for Cisco to pursue its classic market adjacencies in application-related extensions to its hegemony in routing and switching. Cisco also saw video as synergistic with its core network-infrastructure business because it generated bandwidth-intensive traffic that filled up existing pipes and required new, bigger ones.

Meanwhile, Cisco’s move into UCS servers was driven by strategic considerations. Cisco wanted the extra revenue servers provided, but it also wanted to preemptively seize the advantage over its former server partners (HP, Dell, IBM) before they decided to take the fight to Cisco. What’s more, all the aforementioned vendors confronted the challenge of continuing to grow their businesses and public-market stock prices in markets that were maturing and slowing.

Cisco’s reticence to charge into WAN optimization and ADCs also is explicable. Strategically, at the highest echelons within Cisco, the company viewed these markets as attractive, but not as essential extensions to its core business. The difficulty was not only that Cisco didn’t possess the DNA or the acumen to play in higher-layer network services — though that was definitely a problem — but also that Cisco did not perceive those markets as conferring sufficiently compelling rewards or strategic advantages to warrant the focus and resources necessary for market domination. Hence, we have F5 Networks and its ADC market leadership, though certainly F5’s razor-sharp focus and sustained execution factored heavily into the result.

To Be Continued

Now, let’s look at SDN. For Cisco, what sort of market does it represent? Is it an opportunity to extend its IP-based hegemony, like voice, video, and servers? No, not at all. Is it an adjunct market, such as ADCs and WAN optimization, that would be nice to own but isn’t seen as strategically critical or sufficiently large to move the networking giant’s stock-price needle? No, that’s not it, either.

So, what is SDN’s market relationship to Cisco?

Simply put, it is a potential existential threat, which makes it unlike IP PBXes, videoconferencing, compute hardware, ADCs, and WAN optimization. SDN is a different sort of beast, for reasons that have been covered here and elsewhere many times.  Therefore, it necessitates a different sort of response — carefully calculated, precisely measured, and thoroughly plotted. For Cisco, the ONF-sanctioned approach to SDN is not an opportunity that the networking giant can seize,  but an incipient threat to the lifeblood of its business that it must blunt and contain — and, whatever else, keep out of its enterprise redoubt.

Did Cisco achieve its objective? That’s for a subsequent post.

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.

LineRate’s L4-7 Pitch Tailored to Cloud

I’ve written previously about the growing separation between how large cloud service providers see their networks and how enterprises perceive theirs. The chasm seems to get wider by the day, with the major cloud shops adopting innovative approaches to reduce network-related costs and to increase service agility, while their enterprise brethren seem to be  assuming the role of conservative traditionalists — not that there’s anything inherently or necessarily wrong with that.

The truth is, the characteristics and requirements of those networks and the applications that ride on them have diverged, though ultimately a cloud-driven reconvergence is destined to occur.  For now, though, the cloudy service providers are going one way, and the enterprises — and most definitely the networking professionals within them — are standing firm on familiar ground.

It’s no surprise, then, to see LineRate Systems, which is bringing a software-on-commodity-box approach to L4-7 network services, target big cloud shops with its new all-software LineRate Proxy.

Targeting Cloud Shops

LineRate says its eponymous Proxy delivers a broad range of full-proxy Layer 4-7 network services, including load balancing, content switching, content filtering, SSL termination and origination, ACL/IP filtering, TCP optimization, DDoS blocking, application- performance visibility, server-health monitoring, and an IPv4/v6 translation gateway. The product has snared a customer — the online photo- and video-sharing service Photobucket — willing to sing its praises, and the company apparently has two other customers onboard.

As a hook to get those customers and others to adopt its product, LineRate offers pay-for-capacity subscription licensing and a performance guarantee that it says eliminates upfront capital expenditures and does away with the risks associated with capacity planning and the costs of over-provisioning. It’s a great way to overcome, or at least mitigate, the new-tech jitters that prospective customers might experience when approached by a startup.

I’ll touch on the company’s “secret sauce” shortly, but let’s first explain how LineRate got to where it is now. As CEO Steve Georgis explained in an interview late last week, LineRate has been around since 2008. It is a VC-backed company, based in Boulder, Colorado, which grew from research conducted at the University of Colorado by John Giacomoni, now LineRate’s chief technology officer (CTO), and by Manish Vachharajani, LineRate’s chief software architect.

Replacing L4-7 Hardware Appliances 

As reported by the Boulder County Business Report, LineRate closed a $4.75 million Series A round in April 2011, in which Boulder Ventures was the lead investor. Including seed investments, LineRate has raised about $5.4 million in aggregate, and it is reportedly raising a Series B round.

LineRate calls what it does “software defined network services” (SDNS) and company CEO Georgis says the overall SDN market comprises three layers: the Layer 2-3 network fabric, the Layer 4-7 network services, and the applications and web services that run above everything else. LineRate, obviously, plays in the middle, a neighborhood it shares with Embrane, among others.

LineRate contends that software is the new data path. As such, its raison d’être is to eliminate the need for specialized Layer 4-7 hardware appliances by replacing them with software, which it provides, running on industry-standard hardware, which can be and are provided by ODMs and OEMs alike.

LineRate’s Secret Sauce

The company’s software, and its aforementioned secret sauce, is called the LineRate Operating System (LROS). As mentioned above, it was developed from research work that Giacomoni and Vachharajani completed in high-performance computing (HPC), where their focus was on optimizing resource utilization of off-the-shelf hardware.

Based on FreeBSD but augmented with LineRate’s own TCP stack, LROS has been optimized to squeeze maximum performance from the x86 architecture. As a result, Georgis says, LROS can provide 5-10x more network-performance than can a general-purpose operating system, such as Linux or BSD. LineRate claims its software delivers sufficiently impressive performance — 20 to 40 Gbps network processing on a commodity x86 server, with what the company describes as “high session scalability” — to obviate the need for specialized L4-7 hardware appliances.

This sort of story is one that service providers are likely to find intriguing. We have seen variations on this theme at the big cloud shops, first with virtualized servers, then with switches and routers, and now — if LineRate has its way — with L4-7 appliances.

LineRate says it can back up its bluster with the ability to support hundreds of thousands of full-proxy L7 connections per second, amounting to two million concurrent active flows. As such, LineRate claims LROS’s ability to support scale-out high availability and its inherent multi-tenancy make well qualified for the needs of cloud-service providers.  The LineRate Proxy uses a REST API-based architecture, which the company says allows it to integrate with any cloud orchestration or data-center management framework.

Wondering About Service Reach?

At Photobucket.com, which has 23 million users that upload about four million photos and videos per day, the LineRate Proxy has been employed as a L7 HTTP load balancer and intelligent-content switch in a 10-Gbps network. The LineRate software runs on a pair of low-cost, high-availability x86 servers, doing away with the need to do a forklift upgrade on a legacy hardware solution that Georgis said included products from “a market-leading load-balancing vendor and a vendor that was once a market leader in the space.”

LineRate claims its scalable subscription model also paid off for Photobucket, by eliminating the need for long-term capacity planning and up-front capital expenditures. It says Photobucket benefits from its “guaranteed performance,” and that on-demand scaling has eliminated risks associated with under- or over-provisioning. On the whole, LineRate says its solution offered an entry cost 70 percent lower than that of a competing hardware-appliance purchase.

When the company first emerged, the founders indicated that load balancing would be the first L4-7 network service that it would target. It will be interesting to see whether its other early-adopter customers also are using the LineRate Proxy for load balancing. Will the product prove more specialized than the L4-7 Ginsu knife the company is positioning?

It’s too early to say. The answer will be provided by future deployments.

The estimable Ivan Pepelnjak offers his perspective, including astute commentary on how and where the LineRate Proxy is likely to find favor.

Not Just a Marketing Overlay

Ivan pokes gentle fun at LineRate’s espousal of SDNS, and his wariness is understandable. Even the least likely of networking vendors seem to be cloaking themselves in SDN garb these days, both to draw the fickle attention of trend-chasing venture capitalists and to catch the preoccupied eyes of the service providers that actually employ SDN technologies.

Nonetheless, there are aspects to what LineRate does that undeniably have a lot in common with what I will call an SDN ethos (sorry to be so effete). One of the key value propositions that LineRate promotes — in addition to its comparatively low cost of entry, its service-based pricing, and its performance guarantee — is the simple scale-out approach it offers to service providers.

As Ivan points out, “ . . . whenever you need more bandwidth, you can take another server from your compute pool and repurpose it as a networking appliance.” That’s definitely a page from the SDN playbook that the big cloud-service providers, such as those who run the Open Networking Foundation (ONF), are following. Ideally, they’d like to use virtualization and SDN to run everything on commodity boxes, perhaps sourced directly from ODMs, and then reallocate hardware dynamically as circumstances dictate.

In a comment on Ivan’s post, Brad Hedlund, formerly of Cisco and now of Dell, offers another potential SDN connection for the LineRate Proxy. Hedlund writes that it “would be really cool if they ran the Open vSwitch on the southbound interfaces, and partnered with Nicira and/or Big Switch, so that the appliance could be used as a gateway in overlay-based clouds such as, um, Rackspace.”

He might have something there. So, maybe, in the final analysis, the SDNS terminology is more than a marketing overlay.

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.

Embrane Emerges from Stealth, Brings Heleos to Light

I had planned to write about something else today — and I still might get around to it — but then Embrane came out of stealth mode. I feel compelled to comment, partly because I have written about the company previously, but also because what Embrane is doing deserves notice.

Embrane’s Heleos

With regard to aforementioned previous post, which dealt with Dell acquisition candidates in Layer 4-7 network services, I am now persuaded that Dell is more likely to pull the trigger on a deal for an A10 Networks, let’s say, than it is to take a more forward-looking leap at venture-funded Embrane. That’s because I now know about Embrane’s technology, product positioning, and strategic direction, and also because I strongly suspect that Dell is looking for a purchase that will provide more immediate payback within its installed base and current strategic orientation.

Still, let’s put Dell aside for now and focus exclusively on Embrane.

The company’s founders, former Andiamo-Cisco lads Dante Malagrinò and Marco Di Benedetto, have taken their company out of the shadows and into the light with their announcement of Heleos, which Embrane calls “the industry’s first distributed software platform for virtualizing layer 4-7 network services.” What that means, according to Embrane, is that cloud service providers (CSPs) and enterprises can use Heleos to build more agile networks to deliver cloud-based infrastructure as a service (IaaS). I can perhaps see the qualified utility of Heleos for the former, but I think the applicability and value for the latter constituency is more tenuous.

Three Wise Men

But I am getting ahead of myself, putting the proverbial cart before the horse. So let’s take a step back and consult some learned minds (including  an”ethereal” one) on what Heleos is, how it works, what it does, and where and how it might confer value.

Since the Embrane announcement hit the newswires, I have read expositions on the company and its new product from The 451 Group’s Eric Hanselman, from rock-climbing Ivan Pepelnjak (technical director at NIL Data Communications), and from EtherealMind’s Greg Ferro.  Each has provided valuable insight and analysis. If you’re interested in learning about Embrane and Heleos, I encourage you to read what they’ve written on the subject. (Only one of Hanselman’s two The 451 Group pieces is available publicly online at no charge).

Pepelnjak provides an exemplary technical description and overview of Heleos. He sets out the problem it’s trying to solve, considers the pros and cons of the alternative solutions (hardware appliances and virtual appliances), expertly explores Embrane’s architecture, examines use cases, and concludes with a tidy summary. He ultimately takes a positive view of Heleos, depicting Embrane’s architecture as “one of the best proposed solutions” he’s seen hitherto for scalable virtual appliances in public and private cloud environments.

Limited Upside

Ferro reaches a different conclusion, but not before setting the context and providing a compelling description of what Embrane does. After considering Heleos, Ferro ascertains that its management of IP flows equates to “flow balancing as a form of load balancing.” From all that I’ve read and heard, it seems an apt classification. He also notes that Embrane, while using flow management, is not an “OpenFlow/SDN business. Although I see conceptual similarities between what Embrane is doing and what OpenFlow does, I agree with Ferro, if only because, as I understand it, OpenFlow reaches no higher than the network layer. I suppose the same is true for SDN, but this is where ambiguity enters the frame.

Even as I wrote this piece, there was a kerfuffle on Twitter as to whether or to what extent Embrane’s Heleos can be categorized as the latest manifestation of SDN. (Hours later, at post time, this vigorous exchange of views continues.)

That’s an interesting debate — and I’m sure it will continue — but I’m most intrigued by the business and market implications of what Embrane has delivered. On that score, Ferro sees Embrane’s platform play as having limited upside, restricted to large cloud-service providers with commensurately large data centers. He concludes there’s not much here for enterprises, a view with which I concur.

Competitive Considerations

Hanselman covers some of the same ground that Ferro and Pepelnjak traverse, but he also expends some effort examining the competitive landscape that Embrane is entering. In that Embrane is delivering a virtualization platform for network services, that it will be up against Layer 4-7 stalwarts such as F5 Networks, A10 Networks, Riverbed/Zeus, Radware, Brocade, Citrix, Cisco, among others. F5, the market leader, already recognizes and is acting upon some of the market and technology drivers that doubtless inspired the team that brought Heleos to fruition.

With that in mind, I wish to consider Embrane’s business prospects.

Embrane closed a Series B round of $18 million in August. It was lead by New Enterprise Associates and included the involvement of Lightspeed Venture Partners and North Bridge Venture Partners, both of whom participated in a $9-million series A round in March 2010.

To determine whether Embrane is a good horse to back (hmm, what’s with the horse metaphors today?), one has to consider the applicability of its technology to its addressable market — very large cloud-service providers — and then also project its likelihood of providing a solution that is preferable and superior to alternative approaches and competitors.

Counting the Caveats

While I tend to agree with those who believe Embrane will find favor with at least some large cloud-service providers, I wonder how much favor there is to find. There are three compelling caveats to Embrane’s commercial success:

1. L4-7 network services, while vitally important cloud service providers and large enterprises, represent a much smaller market than L2-L3 networking, virtualized or otherwise. Just as a benchmark, Dell’Oro reported earlier this year that the L2-3 Ethernet Switch market would be worth approximately $25 billion in 2015, with the L4-7 application delivery controller (ADC) market expected to reach more than $1.5 billion, though the virtual-appliance segment is expected show most growth in that space. Some will say, accurately, that L4-7 network services are growing faster than L2-3 networking. Even so, the gap is size remains notable, which is why SDN and OpenFlow have been drawing so much attention in an increasingly virtualized and “cloudified” world.
2. Embrane’s focus on large-scale cloud service providers, and not on enterprises (despite what’s stated in the press release), while rational and perfectly understandable, further circumscribes its addressable market.
3. F5 Networks is a tough competitor, more agile and focused than a Cisco Systems, and will not easily concede customers or market share to a newcomer. Embrane might have to pick up scraps that fall to the floor rather than feasting at the head table. At this point, I don’t think F5 is concerned about Embrane, though that could change if Embrane can use NaviSite — its first customer, now owned by TimeWarner Cable — as a reference account and validator for further business among cloud service providers.

Notwithstanding those reservations, I look forward to seeing more of Embrane as we head into 2012. The company has brought a creative approach and innovation platform architecture to market, a higher-layer counterpart and analog to what’s happening further down the stack with SDN and OpenFlow.

Assessing Dell’s Layer 4-7 Options

As it continues to integrate and assimilate its acquisition of Force10 Networks, Dell is thinking about its next networking move.

Based on what has been said recently by Dario Zamarian, Dell’s GM and SVP of networking, the company definitely will be making that move soon. In an article covering Dell’s transition from box pusher to data-center and cloud contender, Zamarian told Fritz Nelson of InformationWeek that “Dell needs to offer Layer 4 and Layer 7 network services, citing security, load balancing, and overall orchestration as its areas of emphasis.”

Zamarian didn’t say whether the move into Layer 4-7 network services would occur through acquisition, internal development, or partnership. However, as I invoke deductive reasoning that would make Sherlock Holmes green with envy (or not), I think it’s safe to conclude an acquisition is the most likely route.

F5 Connection

Why? Well, Dell already has partnerships that cover Layer 4-7 services. F5 Networks, the leader in the application-delivery controllers (ADCs), is a significant Dell partner in the Layer 4-7 sphere. Dell and F5 have partnered for 10 years, and Dell bills itself as the largest reseller of F5 solutions. If you consider what Zamarian described as Dell’s next networking priority, F5 certainly fits the bill.

There’s one problem. F5 probably isn’t selling at any price Dell would be willing to pay.  As of today, F5 has a market capitalization of more than $8.5 billion. Dell has the cash, about $16 billion and counting, to buy F5 at a premium, but it’s unlikely Dell would be willing to fork over more than $11 billion — which, presuming mutual interest, might be F5’s absolute minimum asking price — to close the deal. Besides, observers have been thinking F5 would be acquired since before the Internet bubble of 2000 burst. It’s not likely to happen this time either.

Dell could see whether one of its other partners, Citrix, is willing to sell its NetScaler business. I’m not sure that’s likely to happen, though. I definitely can’t envision Dell buying Citrix outright. Citrix’s market cap, at more than $13.7 billion, is too high, and there are pieces of the business Dell probably wouldn’t want to own.

Shopping Not Far From Home?

Who else is in the mix? Radware is an F5 competitor that Dell might consider, but I don’t see that happening. Dell’s networking group is based in the Bay Area, and I think they’ll be looking for something closer to home, easier to integrate.

That brings us to F5 rival A10 Networks. Force10 Networks, which Dell now owns, had a partnership with A10, and there’s a possibility Dell might inherit and expand upon that relationship.

Then again, maybe not. Generally, A10 is a seen as purveyor of cost-effective ADCs. It is not typically perceived as an innovator and trailblazer, and it isn’t thought to have the best solutions for complex enterprise or data-center environments, exactly the areas where Dell wants to press its advantage. It’s also worth bearing in mind that A10 has been involved in exchanges of not-so-friendly litigious fire — yes, lawsuits volleyed back and forth furiously — with F5 and others.

All in all, A10 doesn’t seem a perfect fit for Dell’s needs, though the price might be right.

Something Programmable 

Another candidate, one that’s quite intriguing in many respects, is Embrane. The company is bringing programmable network services, delivered on commodity x86 servers, to the upper layers of the stack, addressing many of the areas in which Zamarian expressed interest. Embrane is focusing on virtualized data centers where Dell wants to be a player, but initially its appeal will be with service providers rather than with enterprises.

In an article written by Stacey Higginbotham and published at GigaOM this summer, Embrane CEO Dante Malagrinò explained that his company’s technology would enable hosting companies to provide virtualized services at Layers 4 through 7, including load balancing, firewalls, virtual private networking (VPN),  among others.

Some of you might see similarities between what Embrane is offering and the OpenFlow-enabled software-defined networking (SDN). Indeed, there are similarities, but, as Embrane points out, OpenFlow promises network virtualization and programmability at Layers 2 and 3 of the stack, not at Layers 4 through 7.

Higher-Layer Complement to OpenFlow

Dell, as we know, has talked extensively about the potential of OpenFlow to deliver operational cost savings and innovative services to data centers at service provides and enterprises. One could see what Embrane does as a higher-layer complement to OpenFlow’s network programmability. Both technologies take intelligence away from specialized networking gear and place it at the edge of the network, running in software on industry-standard hardware.

Interestingly, there aren’t many degrees of separation between the principals at Embrane and Dell’s Zamarian. It doesn’t take much sleuthing to learn that Zamarian knows both Malagrinò and Marco Di Benedetto, Embrane’s CTO. They worked together at Cisco Systems. Moreover, Zamarian and Malagrinò both studied at the Politecnico di Torino, though a decade or so apart.  Zamarian also has connections to Embrane board members.

Play an Old Game, Or Define a New One

In and of itself, those don’t mean anything. Dell would have to see value in what Embrane offers, and Embrane and its backers would have to want to sell. The company announced that in August that it had closed an $18-million Series-financing round, led by New Enterprise Associates (NEA). Lightspeed Venture Partners and North Bridge Ventures also took part in the round, which followed initial lead investments in the company’s $9-million Series-A funding.

Embrane’s product has been in beta, but the company planned a commercial launch before the end of this year. Its blog has been quiet since August.

I would be surprised to see Dell acquire F5, and I don’t think Citrix will part with NetScaler. If Dell is thinking about plugging L4-7 holes cost-effectively, it might opt for an acquisition of A10, but, if it’s thinking more ambitiously — if it really is transforming itself into a solutions provider for cloud providers and data centers — then it might reach for something with the potential to establish a new game rather than play at an old one.

After F5 Backs Off, Whither Allot?

The strategic disposition of deep-packet inspection specialist Allot Communications has been open to interpretation lately.

In July, rumors and reports suggested that F5 Networks had been in months-long negotiations to acquire Allot. Those talks broke down, with F5 reportedly backing away from the table to reconsider its options. On that score, it’s worth noting that F5 struck a partnership early this year with Allot competitor Procera Networks.

No Deal with F5

Allot is a publicly listed company, traded on NASDAQ under the ALLT symbol. The company currently sports a market capitalization of about $275 million. In its aforementioned acquisition negotiations with F5, Allot apparently was asking for something in the salubrious neighborhood of half a billion dollars, a significant premium on its current valuation.

Since talks with F5 apparently collapsed, Allot chose to change course and announced plans to raise about $72 million through a secondary stock offering. The proceeds from that offering were to be used for “general corporate purposes, including acquisitions, investments in companies or products, or to buy use rights to complementary technologies.”

Course Correction

In what the company seems to perceive as a buy-or-be-bought world, it had reversed its role to the former from the latter. Then, early this month, Allot scrapped those its plans for a secondary offering, citing adverse market conditions.

All of which leaves Allot . . . where, exactly? The company obviously reserves the right to resuscitate its plans for a secondary offering, but it’s also possible that Allot will go in a different direction. Perhaps, in fact, Allot remains receptive to acquisition, by F5 Networks or by somebody else.

Allot has trod a tortuous strategic path this summer. It will be interesting to see where it goes from here.

F5 Deals with Its Virtual Threat

F5 Networks has done well selling its BIG-IP application delivery controllers (ADCs), the devices formerly known as load balancers. Customers and channel partners clearly have derived a lot of value from F5’s ADCs, too.

It isn’t for nothing, after all, that F5 has established itself as the dominant player in the ADC market. As I have recounted in this space previously, F5 has convincingly and repeatedly repelled attempts by Cisco Systems to dethrone it. Even when it was a the old Cisco, the networking colossus that bestrode the globe, it couldn’t beat F5 at the load-balancing game.

Questions to Answer

Now, though, I have begun to wonder whether the vicissitudes of technological change might do to F5 what Cisco was unable to accomplish. Could the seemingly endless push in data centers for increased virtualization, with its attendant cost savings, cut into F5’s ADC cash cow? Could virtualized ADCs (vADCs), sold at lower prices than purpose-built hardware-appliance ADCs, eat into F5’s top and bottom lines?  To what extent are these vADCs capable of doing the work that physical ADC (pADC) appliances perform today?

F5 has been pondering the same questions, and it has provided some answers in a column written for Enterprise Systems by Alan Murphy, a senior technical marketing manager. To summarize, Murphy acknowledges that vADCs have been considered replacements for pADCs in the data center, but he advises strongly against their adoption. That’s obviously the sort of advice one would expect from F5 — and I’m sure proponents of vADCs will contend that there’s a self-serving element to F5’s guidance — but there’s also plausibility to the points F5 raises.

Fundamentally, F5 argues that pADCs are superior to vADCs in mission-critical scenarios involving application security, optimization, and availability at the data-center edge. According to F5, pADCs’ purpose-built hardware is optimized to perform “application delivery, SSL acceleration, and compression.” In contrast, vADCs, which run on industry-standard hardware and often share computing resources, can’t scale application traffic or perform to the same degree.

More — or the Same — for Less

F5 does concede that vADCs are appropriate for some applications. Their portability, affordability, and ease of deployment make them good candidates, for instance, for application-development environments, where costs and logistics preclude deployment of pADCs. While that might seem like a minor concession to the vADC camp, F5 allows that virtualized load balancers also have their uses alongside application-specific services and virtualized workloads such as SharePoint.

In the end, F5 envisions the coexistence of pADCs and vADCs. In the near term, as F5 contends, it’s likely true that pADCs will retain their grip on mission-critical data-center applications.

Looking further ahead, however, it’s harder to say how markets and technologies will evolve. As today’s tumult on the public markets suggests, IT cost cutting could be the one unvarying constant that drives ongoing change in this industry. In that vein, we should watch not only the progress of virtualized load balancers, but also, on a higher level, the virtualization of network infrastructure represented by software-defined networking and protocols such as OpenFlow.

There’s no question that managers of data centers at enterprises and cloud service providers will be on an endless quest to slash capex and opex. If technologies can do more — or even the same — for less, they figure to find patronage.

Cisco and RIM: Hard Times, Different Situations

A morbid debate has ensued as to whether Cisco or RIM is in worse shape. It’s an unseemly discourse, but it seems obvious to me that Cisco, regardless of its current woes, remains in a better, stronger position than RIM, both today and well into the future.

That said, let me be absolutely clear that I believe Cisco has entered a period of decline, perhaps of the irrevocable sort. The broad industry trends — commoditized wiring-closet switches, stiff competition in the data center and the network core, the rise of cloud computing, and so forth — are not its friends. To make matters worse, Cisco is suffering from its own imperial overstretch, and from a cultural malaise that afflicts and challenges all big corporations that reach a certain stage of maturity.

Not the Same

This Cisco, the one you see today, is not the one that ruled the networking industry late in the last century and early in this one. That beast, which seemed so unstoppable on its path to dominance — capturing and keeping customers, charming partners,  drawing prospective suppliers, and dazzling industry analysts — seems to have left the building. It has the same head, figuratively and literally, but it’s uncoordinated now and tends to get in its own way at least as often as it bulldozes the competition.

Even so, Cisco is a long way from dead. It has a prodigious installed base of customers, some major partnerships that still matter, and a chance to step back, reflect on what’s happening in the market, and alter course accordingly. It won’t be easy — some believe Cisco’s leadership is better at building than fixing  — but Cisco need not slide into an industry abyss.

RIM, too, has an opportunity for renewal, but its situation is far more daunting. As with Cisco, the trends — an app-driven market dynamic; consumerization of IT and “bring your own device” (BYOD) to work; the strength of Apple at the high end of the smartphone market, Google Android nearly everywhere else, and low-cost competitors in the developing world; the rise of mobile-device-management (MDM) suites that can support heterogeneous mobile platforms — are not in its favor. Also like Cisco, RIM has lost its way, failing to recognize foreboding trends and lethal competitors until serious damage had been done.

Bigger Challenges, Fewer Resources

Still, RIM is worse off in many respects. First, it’s no longer an industry leader. It’s been usurped by Google’s Android and by Apple in smartphones, and there’s a danger that Microsoft, and perhaps even HP, could knock it further down the charts. Cisco, notwithstanding its current hardships, doesn’t have that problem; it’s still number one in enterprise networking (switching and routing), though competitors are chipping away at its market share and it has lost ground in other important, faster-growing markets, such as the application delivery controller (ADC) space, where F5 leads.

Furthermore, Cisco still has customers that will buy into the brand and the higher prices that accompany it. That could change — nearly everything can change — but Cisco retains that benefit today. There might fewer of those customers than there were a couple years ago, but the population of Ciscotown remains considerable. Unfortunately for RIM, the brand-equity die has been cast, and it has suffered a decline not only in the eyes of consumers but in many enterprises as well. Apple iPhones and iPads are proliferating in enterprise settings and vertical markets, often supplanting BlackBerry devices, at a rate few predicted.

RIM also has fewer resources than Cisco. True, it’s fighting competitive battles on fewer fronts than the networking giant, but Cisco has the option of reining in its aspirations and allocating its ample resources with greater strategic focus. RIM can only do so much.

Mitigate Risk or Roll Dice?

It’s ironic that, just a short time ago, some analysts and pundits were suggesting that Cisco buy RIM. My point is not to mock them — this industry will humble anybody who tries to predict its course — but to illustrate just how much a combination of strategic missteps and the vagaries of fate can change the game in relatively short order.

The best anybody out there can do is to find a balance between risk mitigation and success probability, which often (but not always) are closely interrelated. Sometimes, though, you need to take a big risk to qualify for a big reward.

Cisco can still play some risk-mitigation cards, while RIM needs to roll the dice.

F5 Bids to Strengthen Data-Center Grip

Acquisitions always qualify as big news because they’re dramatic transactions. They are sudden, sometimes surprising, and they can have significant commercial, financial, industrial, and technological implications. They roil industry waters, ultimately leaving some vendors capsized and others navigating toward bold horizons.

Product announcements can be overshadowed amid periods of M&A ferment, so it’s important that we pay sufficient attention to product launches that have potentially far-reaching consequences.

Toward the Dynamic Data Center

One such announcement occurred today as F5 Networks, the leader in the application delivery controller (ADC) space, announced its BIG-IP v11 software release, scheduled to reach market in the third quarter. F5 is emphasizing two major aspects of the release: the realization of its vision of a “dynamic data center,” in which service provisioning is expedited through an application-centric view of network infrastructure and resource availability; and enhanced, dynamic security services that are intended to prevent attacks on networks, applications, and data.

Over at F5’s DevCentral, Lori MacVittie has been setting the stage for today’s announcement for a while, discussing various intractable operational and technological challenges — all of which, perhaps not surprisingly, can be addressed by the new release of BIG-IP. No wonder, then, that she was eager to provide her perspective on what today’s announcement means.

Piecing IT Together

In her view, the “game changing” pieces of the new BIG-IP are iApp, which moves the focus of BIG-IP configuration from network-oriented objects to application-centric views; ScaleN, which introduces the concept of “Device Service Clusters” and facilitates targeted fail-over of application instances, allowing customers to scale out across CPUs or devices, managing them as one pool; and Virtual Clustered Multiprocessing (vCMP), which makes ScaleN possible.

When you consider those three components together, she contends, “you now have capabilities in the application delivery infrastructure with similar benefits and abilities as those found previously only in the server / application virtualization infrastructure: automated, repeatable, manageable, scalable infrastructure services.”

Strengthening Data-Center Claims

What it means from a business standpoint for customers is increased cost savings from greater IT efficiency, improved application-centric resource utilization, and automated (thus faster and less costly) application provisioning.

From an industry and vendor perspective, what is means is that F5 bolsters its case for BIG-IP as an essential element in data-center management. If this release of BIG-IP and its underlying strategy are successful, F5 not only takes greater command of the ADC space, but also will strengthen its claims on some critical real estate in enterprise and service-provider data centers.