Speaking with other individuals in the industry about what SDN is, specifically how we qualify and quantify it, has lead to me to quite a few conversations with people about how many people think of SDN as an NBAR / QoS on steroids solution instead of looking at it as higher level policy framework that can be applied across infrastructure. I, personally, can subscribe to the thought process there.
We got side tracked in the last Class C Block podcast I was invited to participate in, about what SDN is and how we can use it and I just recently listening to the latest Healthy Paranoia podcast where the discussion of how SDN could impact the security realm was had. And the key word that I kept hearing was policy. Policy that needs to be applied here, and policy that needs to be configured there.
I like the idea of defining a framework for our infrastructure in that we can mold the technology policies that we have within our organizations to the business. This is the fundamental reasons why IT exists. We’re here to transcribe business policy into technology solutions. That said sometimes there are very large gaps in translation from business policy into technology, and this brings me to my point.
If SDN, within the next 5 to 10 years, is going to yield us anything we need to make sure that we have not only engineers that can design, build, and deploy these next generation solutions, but they also need to understand the business side of the house a bit deeper. Right now we’re afforded the ability to understand the business logic on a lesser level as we’re living within a world of constraints defined, in majority, by the hardware and software we have deployed in house. To the point where businesses are willing to change their business policy to accommodate the limitations of their technology. The obvious constraint from the business side of the house that can be read into these new policies would be the financial impact. Being more network engineer than anything, the best I can align this with is having multiple upstream peers, all with different monetary costs and having the ability to intelligently shift flows in accordance with fiscal requirement. Right now its a lot of kludge edge policy that needs to be modified and addressed relatively regularly depending on demands within the network.
The more I think about it and the harder I examine the problems and pain points that organizations face and why so many of us are clamoring at the thought of having that panacea of flexibility that all of this hype promises to offer, we need ensure we really understand exactly what it is we’re trying to accomplish. From a business perspective, as well as technological. Otherwise, years from now we’ll look back at our next generation ‘software defined’ infrastructures and be facing the same problems we’ve been faced with over the previous decade. Except, this time we’ll be faced with unraveling a larger ball of yarn with all of the ‘code’, read pseudocode…ish…whatever you want to call it, that gets developed along the way.
Maybe I’m the only one that has seen this problem within organization but I still feel it necessary to at least bring this point to light.