The ‘Software Defined’ Policy Dilemma

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.


2 thoughts on “The ‘Software Defined’ Policy Dilemma

  1. At this point and from what I’ve witnessed the main Dilemma is between the Devs and the Network Engineering Teams…you just identified exactly why you would use Software Engineering to help mitigate roller coaster affects of Network Traffic (the Problem: the last sentence of para. 4) and apparently..the SDN guys are the solution?!?(I enjoy statistic based logic coding..although it is very easy to screw up the math)..So a better title would be ‘The SDN Human Dilemma’?.?; hope I at least make some sort of sense…not meant as (a) disparaging remark(s)

    Full Disclaimer: I work as an IVR Developer type this is complete opinion..and can probably be punched full of holes..

  2. Any and all view points welcome. I’m not a software engineer by any stretch of the imagination, nor do I pretend to be. I just thought, after talking with a lot of my fellow infrastructure people, that this needs to at least stay on the map moving forward. We’ll see a nice blend between software and infrastructure people in the coming years and we’ll both learn from each other. If, of course, the organization supporting them wants to remain relevant in the technology space.

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s