You’re not ready for SDN
You’ve read the articles, been to the conferences and talked to the vendors. Software Defined Networking (SDN) seems like it could revolutionize your network and you want to dive in. If you’re like most enterprises, no matter how much you want it, you’re just not ready. Full blown automation of network resources requires a level of IT service maturity and technical skills that are a step or two beyond your capabilities and risk tolerance today. According to 451 Research’s end user networking study (Networking Wave 11), you’re slightly more likely to have rolled out IPv6 (13 percent of you) than to have dabbled in SDN (11 percent). And this rate of adoption for either is low for a good reason. The operational risk factors for networks are higher than in other technologies. You’ve gotten good at compute virtualization, but network virtualization is different. Where the impacts of single operations in server virtualization can be limited to a single instance, in networking, a single operation in a network tends to impact many instances.
To gain the benefits of SDN, you’ll have to lower that risk. There are capabilities that are integrated into virtualization platforms and switch management systems and they’ll help to integrate some static controls, such as prioritization, template provisioning and simple connectivity. These are good starting points, but address only part what can be achieved. They’re also a significant investment that is better understood in terms of what value they can deliver in your environment. This doesn’t mean that you should put off what is a multistep journey. You can get to a point where the many benefits of SDN can be practically deployed, but it will take work and it’s important to start now. You’ve got to start with an understanding of what specific goals you want to achieve, and consider who the network is really serving. We need to start with an understanding that SDN is a means, not an end in itself. First steps with SDN will be most successful where risk and disruption are low. That means that the initial steps shouldn’t be controlling the network at all. Rather, you start with monitoring and alerting on the results. Once you’ve built competence in manipulating the interfaces at your disposal, you can move forward with confidence that you can trust the information you’re gathering and the means to gather it.
Where to Start?
While there has been significant focus on selecting an SDN controller or platform as the first step in an SDN plan, it’s important to start the journey before what will be a large commitment. Your team will need to build experience in automation and data handling. Monitoring your virtual environment can be a simple and safe step. Pull operational statistics from your virtual networks. Archive equipment configurations. It will give you visibility that you probably don’t have from a network management system. You will have to build both the systems to run the queries, as well as the data storage environment. It doesn’t have to be complex. You should approach this as a learning experience and expect that whatever you build at this stage may not follow to a final system. Some infrastructure management software can form a base for this stage, but ensure that your team is mastering automation basics. Training in fundamentals, such as scripting languages may be needed. Once you have mastered the virtualization environment, you can start to pull in information from the native network. At this stage, you shouldn’t have had to make any significant changes to your existing network, but you’ve made it through the first hurdles. Bridging, Not Busting Silos Once you have got the data, distribute it to other teams. Let the storage team know when their network use peaks.
“To capitalize on later stages of virtual network control, there will have to be bridges built between technology silos”
Let the application teams know where and when their systems are busiest. If you don’t already share network management data, this is the first step in building the coordination and collaboration that will have to exist in order to accomplish bigger and riskier tasks. To capitalize on later stages of virtual network control, there will have to be bridges built between technology silos. Network teams will need to understand the needs of application, storage, server and security departments.
Bridging, Not Busting Silos
Once you have got the data, distribute it to other teams. Let the storage team know when their network use peaks. Let the application teams know where and when their systems are busiest. If you don’t already share network management data, this is the first step in building the coordination and collaboration that will have to exist in order to accomplish bigger and riskier tasks. To capitalize on later stages of virtual network control, there will have to be bridges built between technology silos. Network teams will need to understand the needs of application, storage, server and security departments.
With some basic automation capabilities in place, you can consider what many see as the first steps in SDN–moving to equipment with control capabilities. This can be either automating existing equipment or adding equipment with automation capabilities. This doesn’t have to be OpenFlow, OvSDB or Opflex, but it can be worth sticking a toe in these waters to gain experience. Most networking vendors offer programmable control in some form, so this may be available with a software upgrade. Lower risk projects to target at this point are dynamic traffic inspection (directing replicated traffic to IDS systems) and initial configuration of new networking gear (bringing up new sites or services). These are capabilities that will establish a foundation of technical competency.
Dynamic control is the final step in the SDN journey. There are various project paths that will be determined by the needs of your organization, but with a solid base, you’ll be ready to move forward with platforms or systems with an understanding of what they can do for you and how you can put them to work effectively.