Over a million developers have joined DZone.

A Heated Discussion About SDN as Intel Enters the Market

DZone's Guide to

A Heated Discussion About SDN as Intel Enters the Market

· Cloud Zone ·
Free Resource

Learn how to migrate and modernize stateless applications and run them in a Kubernetes cluster.

The arrival of Software Defined Networking (SDN) or Networking-as-a-Service could be a very significant sea change in IT departments and we're keeping a close eye on new developments like the news from Intel today.  

The chip-maker announced that they will be using their new low-power Avoton Atom products as the engine behind new software defined networking capabilities.  MojoKid had a good explanation of SDN if you're still unclear about it:

In a typical network, a switch is programmed to send arriving traffic to a particular location. Both the control plane (where traffic goes) and the data plane (the hardware responsible for actually moving the bits) are implemented in hardware and duplicated in every switch. Software defined networking replaces this by using software to manage traffic and monitoring it from a central controller. Intel is moving towards such a model and talking it up as an option because it moves control away from specialized hardware baked into expensive routers made by people that aren't Intel, and towards centralized technology Intel can bake into the CPU itself.

The comments for the news story included adamant arguments addressing some of the concerns that have been emerging around SDN.

Several of the comments were pointing to the recent NSA/PRISM story as an example of why it's not such a good idea to centralize networking control in an SDN.  

tbonefrog said:
SDN makes hacking and covering tracks so, so, so, much more potent, quicker, and easier. Now you don't just have the NSA to be afraid of. As with the entire history of the Internet, they will not worry about security until their baby has grown into a giant, and then they will attempt to tack some kind of loincloth on it and declare it secure.

There was another interesting comment about taking another direction instead of what the commenter called 'creating software defined workarounds'.

Another concern I've run into about SDN is outages.  There's some unpredictability around SDN's ability to self-correct and come back online if there's a failure.  However, I doubt that this problem will become a major issue as these systems improve.  The simple economic argument in favor of using SDNs will be hard to pass up even with these concerns.  From another commenter

You're going to lose the argument hard on this one. One appeal of SDN is cost savings; cheaper hardware, easier management, less net complexity, better asset utilization, etc. There is no possible way you're going to convince anyone that has a budget and competitors (that includes governments, BTW) that they will be better off with systems that cost more. Forget it. 'Security' arguments won't preclude it either.

Join us in exploring application and infrastructure changes required for running scalable, observable, and portable apps on Kubernetes.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}