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