Image

The Ghost of Application-Aware Networking

There’s a certain phrase I keep going past lately which always causes my muscles to tense and occasionally sends a shiver up my spine. Coincidentally (or not…) it’s nearing Halloween, so I thought I’d share my ghost story. This one, I swear, is all true.

Image

It was the summer of 2005. SOA was in heavy rotation in the application realm. And it clearly stood to reason that an architectural shift that depended on the network for execution should be something that a networking provider like Cisco would have something to say about. So there were meetings. Oh, were there meetings.

There were SONA (Service-Oriented Network Architecture) meetings, in which marketing executives explained to each other how web services such as SOAP and XML on top of an IP platform could support assorted network applications and services, which meant everything from transport enhancements to “collaboration” apps.

There was a secretive group building an appliance to do Application-Oriented Networking, which basically tracked and optimized traffic for specific transactions from source to destination. Over time it also got positioned as an application security play, a load balancer, a WAN optimization engine, and probably a few other things I’m forgetting now.

Then there was the original Catalyst-based load balancer technology which was merged with the FineGround acquisition to create the ACE “application delivery controller”.

(At one point the ASA VPN team decided they also wanted to market their load balancing capabilities to better compete with F5. So I arranged for reps from the AON, ACE and ASA teams to each speak to the same analyst, one after the other, on “inquiry” grounds for “help” with positioning. The analyst did not disappoint me.)

In an effort to contain and coordinate the…marketing exuberance…of the various teams within the SONA framework, ACE, WAAS and AON had a shotgun wedding from which they emerged as Application Networking Services, the next big market bet for Cisco.

And it all went…nowhere. The ISR and Catalyst AON service modules were EOL’d after about a year, the appliance somewhat later due to certain customer commitments. ACE was a troubled product: starved for resources, always half a year or more behind the leaders in terms of features, staffed by an ever-shifting cast. Reactivity, an XML gateway (with firewall and load-balancing services!) was acquired, and then shut down a few months later. Within 18 months, SONA went from something that people hoped to make their careers on to a graveyard for the same careers. The word “Application” was rarely mentioned in the halls above a whisper.

What happened? Virtualization happened. The next 2-3 years were spent reworking access networks to talk to vNICs. Cloud happened. Orchestration became a bit more real.

But there was a more basic problem: claiming the network could be and do more than it has been, without really making it any different.

And now “application-aware networking” has been resurrected—stronger and more powerful than ever before! But is it really that much different this time? Well…there’s this movement afoot to rearchitect networks using computer science principles. There is much promise in this. However, it does not necessarily change the fundamental nature of the network; in other words, SDN gives an administrator more tools for customizing how specific flows move across the network, but the network itself is doing the same thing it’s always done: obediently passing bits around.

Cisco’s current take on “Application-Centric Infrastructure” appears to really be a switch-based take on infrastructure orchestration and network service chaining. Again, these are good things in themselves, and developing a more lightweight, flexible and repeatable orchestration model that might be extended in other industry-wide efforts could be very beneficial. That said, having infrastructure orchestration under the control of a network vendor is not the same thing as the network becoming application-aware. Having it organically paired with service chaining allows an administrator to predefine or alter policies for well-understood applications, but this still isn’t network-level app awareness. (Obviously there are some suppositions here which could be offbase, and a big part of me would really like to be wrong about some of this. I await Nov. 6th with interest.)

Meanwhile, Embrane, which lives a bit further up the stack, has been banging the NFV drum for some time, and is now drafting on the “application” chatter to put a sharper focus on the business purpose for NFV. Vyatta applies a more explicitly compute-centric line of thinking to the same problem.

These different approaches to service chaining certainly provide much more responsive and customizable methods for securing and optimizing application delivery than the aforementioned products which still make visitations in my darker dreams…but I still want more.

Conceptually, I like Plexxi’s Affinities idea, which as I understand it brings data from various management sources into an ever-evolving repository from which analytics can surface pertinent information about application component relationships. Admins or the controller then apply appropriate policies. In other words, there’s a certain amount of machine learning going on about current behavior of any vanilla application that can help support the admin in defining policy. By extension, those policy profiles could be applied automagically to other new/unknown applications with similar behavior. This is a much clearer move towards what I understand “app-centricity” to mean.  Jason Edelman (@jedelman8) has written a very good pair of blogs that go into the Affinities concept in more detail; this one gets more into where those ideas could be taken from an architectural standpoint.  I’m more interested in extending machine learning about applications for better network automation.

It must be noted that apart from all this app-talk in portions of the network world, there’s an argument for letting transport just be transport and having the intelligence at the edge. It might also be noted that in many cases (not all) that’s really a cover for the argument about who should design and run network services, not a reimagining of how they might be designed. In any case it’s still fundamentally an infrastructure-centric debate. Which is not to say it’s invalid; I’d just like to see better integration between different portions of the greater system vs different lines of demarcation.

One thing I know for sure is that one of the more common definitions of insanity unquestionably applies here.

Image

4 comments on “The Ghost of Application-Aware Networking

  1. I could write a very similar story about “ghosts of virtualization”. It started with System 60 and finally found its way into a hypervisor on x86. Yet 90% of enterprise software does not run in VMs. And now we have containers with very similar pedigree.

    The real driver behind this deceptively complicated and counter intuitive progression of technology and market is the first principle of networking “the intelligence resides at the edge and core is dumb” is yet to be proven wrong and the second principle of networking “the one who controls the edge controls the network”.

    • Thanks, good point. When I first posted this, Dimitri Stiliadis (@dstiliadis) pointed me at this classic piece from 1996: http://www.rageboy.com/stupidnet.html. One of the snippets I most liked in that piece was the comment that the network should have “a small repertoire of idiot-savant behaviors”. That is, there is room–and good reason–for *certain types* of intelligence to exist within the fabric to allow it to function more autonomically than has been true in the past. I think a better principle might be “automate where we can, abstract where we must”–I discuss this in a bit more detail in the first post on this blog (http://theborgqueen.wordpress.com/2013/04/14/how-to-stop-worrying-and-learn-to-love-the-borg/). I’m not a fan of abstraction for the sake of abstraction–more layers can simply obscure complexity rather than actually reduce it.

      What Mike Dvorkin (@dvorkinista) described in a Twitter conversation on 10/30 in fact sounds more along the lines of where I think we should be going, though certainly none of that came across in this morning’s briefing (and I couldn’t help but notice a conspicuous absence of SONA in Chambers’ narrative about the “consistent vision”…) I’m looking forward to going through the “ACI” materials in the next few days to figure out where things actually landed.

      But I do think the smart/dumb network debate is a bit tired and overly binary, especially given the capabilities for both automation and granular policy application that have evolved in various corners of the networking world in the last couple of years.

  2. Pingback: SDNCentral SDN and NFV Weekly Roundup — November 8, 2013 -

  3. Haha – I was completely unaware of those things back in 2005 (too busy working on automated J2EE+Oracle deployment of a complex n-tier app, amongst other things). Good to know SONA and AON existed in theory. But maybe if they were resurrected today they would be more successful (SONA would certainly have a place in controller federation, amongst other things).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s