SDN. In the end, it’s about the apps

#F5 - #ADN, not #SDN should be the end goal.

When Lori and I were writing import/export routines for a large software vendor, we had a phrase to remind ourselves that what we loved was not necessarily the all-important part of what we were doing. We used to say “It’s all about the data”, almost as a mantra, to keep our team (I was project lead, she was tech lead, so really our team) that when translating, accuracy and faithfulness to the data mattered, code was just a means to that end. At that same company we used to say “computer chips are not potato chips” just as often, but that’s a completely different blog related to hiring practices. But it does give me a great graphic to slip in right here.

One of the things that happens when a new high-tech buzzword comes out in the hyper-connected world we live in is that every vendor under the sun and a lot of non-vendor industry pundits try to define it to best suit their needs or world-view. Most of us participate in this game, as evidenced by any number of definitions for the term “cloud computing”. The fact is that for those not tied to a vendor/product, this is often just an attempt to fit the new buzzword into our worldview.

SDN seems to have followed this path. Thought leaders like Lori have driven it to a reasonable definition, but there is still a ton of confusion out in the IT realm about what/where/when – even though both vendors and open source groups have put products/projects out there.

One of our co-workers referred to SDN on a team email alias the other day, and it sparked a conversation about definitions, which of course sparked this blog. In the end, what I want SDN to be is actually ADN – Application Defined Networking. Because whether it’s manual or automated, in the end it is all about the apps. Can they be reached, are they responsive, and are they optimized. There are very few business or end users in the world that care about your network – unless they cannot get to their apps, or their apps are not working. And not “apps” actually, but “app”. The one they are trying to use. You are unlikely to ever hear normal users going “sheesh, you know, I really like company X’s stuff, but there’s just too much packet loss when accessing their website. Because they don’t care what the  cause of performance issues is any more than most drivers care about what went wrong with their care beyond the price to fix it –.because the real problem, for them, is they can’t get where they were going.

So to me, the mandatory evolution is to application aware. I could argue that F5 has been doing that for years, but not in the same sense that ADN promises. I would call ADN “App Aware SDN”, just for simplicity’s sake. ADN promises to be automated, aware of overall app performance, and adjustable. While I’d love to claim that app developers should have the ability to adjust network resources to accommodate the needs of their app (as SearchSDN defines ADN), network resources are shared and finite, we don’t want to go to a place where a developer can hog them, because it could start a priority race pretty quickly. But ADN promises to stay on top of resource allocation and make certain the app is doing what it’s supposed to, given the environment and its priority. Even when things go wrong.

Of course, ADN requires SDN, so the confusion will have to be cleared up, and we’ll have to get some rock-solid SDN implementations that the implementers are willing to talk about publicly, but all things in good time. You don’t introduce the level of change SDN requires without it requiring cycles and budgets, so patience is indeed a virtue, even in the non-stop high-tech world.

And this is important, because I want my to-be-written potato chip app to be more responsive than all those silly business apps that are using my resources…