Making the leap to SDN? Don’t jump in blind. It helps to grasp what software-defined networking is, firstly, after which what it might do for you.  

Then it’s smart to understand the whole inner workings of an SDN controller, the diversities between products offered by established vendors and begin-ups, and whether open source and bare metal switching may very well be an option. Lastly, learn your individual network — will it even support SDN or require a wholesale rip-and-replace? — after which learn out of your peers about their experiences. Here’s an 11-tip guide on the best way to prep for SDNs:

1) Educate yourself on it: Many organisations still have no idea what software-defined networking is, what it’s constituted of, and the way they may profit from it. It’s obvious, but familiarity is step one to understanding how SDN should help or hinder your business network (inspect this SDN Primer). Google, Facebook, Yahoo and Amazon Web Services regularly tout the advantages and steer the criteria work, but those organisation aren’t the mainstream; they’re at the bleeding fringe of everything in compute and networking. Read up at the various flavors and iterations of SDN, what’s new, what’s old, etc. You will even get a hold of your personal definition.

2) Know what it is advisable to do: Goldman Sachs wants open standards, commodity scale architectures, independent and programmatic data and control planes, virtualised Layer 4-7 services, merchant this, open source that… Well-nigh the full ball of wax across all of its networks. SDN was targeted initially on the data center but now the enterprise WAN is a first-rate focus for the automation and orchestration benefits of SDN. Would you like a centralised or distributed control plane? Why or why not? A few of the more compelling SDN applications are analytics and packet monitoring — TAP — as a result of SDN’s ability to rapidly steer traffic with only some mouse clicks. Orchestrating and automating the network through software can save on capital and operational expenses besides, proponents say. Determine what your goal or objective is with SDN and implement accordingly, yet prudently, gradually.

3) Consider security implications: Centralising all control of the SDN may make life easier for the network operator; nonetheless it can even offer a single point of catastrophic failure or attack for a hacker or malicious content. How would a controller take care of outages that require re-routing of traffic? If a hacker gains control of your controller, could that intruder bring your network to its knees?

4) Imagine where to begin: As mentioned above, SDN was initially and still is concentrated on the data center where much of the automation and orchestration, capital and operational cost reduction benefits are obvious. However the enterprise WAN is now being mentioned more frequently as a primary focus for SDN. WANs can equally enjoy the automation and simplified management SDNs bring, proponents say. Major IT trends together with SaaS, private clouds, BYOD, mobility and voice/data convergence are stressing the standard of links in an enterprise WAN. And WAN links now require improved security, lower latency, higher reliability and support for any device in any location to deal with these trends. SDNs might be useful enterprise IT accomplish this without the expense of upgrading individual WAN links, advocates say, and might allow for application and traffic prioritisation, ease of provisioning and enhanced security.

5) Weigh the right way to start: Start small, people with experience say. Carve out a small slice of a test and development network for SDN experimentation in place of going for the entire shebang. That way, if anything goes wrong, you are not affecting the entire production network. Once things are humming along nicely, you could gradually meld the SDN pilot back into the production network and carve out another little piece to transition over. And when things are running smoothly, SDN can facilitate the mix of the advance and operations networks right into a single DevOps environment where new capabilities might be quickly turned up into production mode when they are developed and tested.