Broadcom is acquiring semi-rival Netlogic in what’s surely a big buy, but the range of products in the Netlogic portfolio make it hard to be sure just what Broadcom’s target for the deal is. Netlogic generally makes smart chips, things that are a bit like the network processors of old but more focused on packet processing and inspection than on protocol hosting. Their products make sense in smart appliances as a way to separate real-time streams from the packet/web chaff, but they could also figure rather prominently in networks as packet handling tools. In fact, the company has some biggish deals with network equipment vendors in that area. Netlogic has also been looking deeper into the cloud and data center of late, not only for security but also even for application performance management.
One of the things that the move demonstrates is that packet processing and intelligence is probably a key element in any move to create service value that has a network component. The network’s ability to recognize services discretely often depends on the examination of data streams, particularly where the network transport web has no integrated service layer that can inject application knowledge/awareness. That’s one of the reasons we think that whether you’re talking about enterprises or service providers, the service layer is important.
Juniper held its “Innovations Day” meeting yesterday, but the outcome appears to me to have been more evolutionary than revolutionary. The Street is divided on whether Juniper can create a significant upside in revenues in the near term with the products it’s announced in the past (some of which are targets of the Cisco attack I noted yesterday). UBS now concedes that it’s unlikely Juniper will make a major headcount reduction and thus seems to be reconciled to a year or so of anemic profit growth because of the longer selling cycle on the hardware that’s already been announced.
I don’t understand either Cisco or Juniper, frankly. Network gear has a fairly long expected useful life and it’s expensive, so you can’t swish it around at will to track the ebbs and flows of market needs. For years it’s been clear that software has to be the impedance-matching layer, the adapter that makes glaciers look agile. That’s how it’s worked in IT for decades, and how it has to work in networking now. Cisco seemed to have realized this early on, but its software activity was (typically for Cisco) focused on near-term sales goals and it never established any true strategic position for itself within Cisco or its products. I’d argue it still hasn’t. Juniper caught on to the notion that software had to somehow be linked strategically to the network and came up with their whole “Junos ecosystem” thing, but they’ve been unable to make anything of it other than an enhanced operations tool. Get your heads out of the bits, guys, and look at the IT world. What makes the hardware-to-user connection there? Learn a lesson. Watching these guys is like watching two guys fighting on a raft about to go over the falls. Sometimes you have to view “winning and losing” in a broader light.
Many of those who have followed my views and work over the years know about my open-source ExperiaSphere project, designed to create Java proof-of-concept execution for service-layer technology that tightly couples network assets to service monetization plans. I’m pleased to say that I’ve completed a very extensive document describing how the ExperiaSphere framework could execute multi-screen video applications. This document was produced with input and review from seven global network operators, and it’s the most extensive description of multi-screen that you’ll find anywhere. It’s available at http://www.experiasphere.com/MultiScreenVideoAppNote.zip. I’ve included the document PDF (almost 25 thousand words) and all 27 figures in a separate file to make reference easier. We’re no longer taking comments on the document for future revision, but I’d still be happy to hear from anyone with thoughts on it!