It’s ironic, but true: software-defined networking (SDN) is tough to define. SDN solutions are not things you can touch, like a hardware gateway. They are not made of plastic or metal. They do not physically plug into anything.
Perhaps that’s why agency network administrators are, even in late 2017, still trying to wrap their minds around the concept of SDN, despite its known benefits. They know that, after the initial set-up frenzy, the tools will likely make their lives as network managers much easier and provide greater agility, security, and cost-savings. But still they ask: How do I approach SDN and make it work for my agency?
These questions aren’t surprising, since SDN implementation can pose significant challenges. Millions of dollars worth of legacy network equipment, accumulated over the years and well integrated into the IT infrastructure, need to be replaced. Migration brings with it security risks, high upfront costs and complexity, and the potential for downtime.
But there is the potential for a huge payoff on the other side. Adopting SDN sets your agency up for a more efficient future, and lays the groundwork for greater innovation at less cost.
Figuring out if now is the time to begin building toward that future should be undertaken in the same manner as other major technology initiatives: through testing and analysis. Before diving into the SDN waters, it’s a good idea to set up a test environment, if possible. Simulate production so you can gain a better understanding of whether or not SDN is appropriate for your agency.
In this environment, test and analyze quality of service, costs, and risks to see if SDN is the right choice, right now. Here’s a closer look at each of these things and how they may impact your decision.
Monitor network performance for better quality of service
Two of the big reasons agencies are implementing SDN is to remove the potential for human error and simplify network management. The idea is to make networks more automated so as to deliver faster, more reliable, and overall better quality of service.
Monitoring the network during testing will provide some insight into whether or not this goal will be achievable through SDN. Tag what is affected by SDN and what is not, and closely track availability and uptime. Use network performance and configuration monitoring tools (which you may already have in your arsenal) to assess your SDN deployment. If you see that SDN is positively impacting uptime, you’ll feel more comfortable making the move.
This proof point may also make it easier for you to sell the promise of SDN to your CIO. Indeed, you’ll need all the ammunition you can get, especially given the next point.
Understand that SDN will cost you, but it could also save you
The cost of migrating toward SDN will, of course, vary depending on the agency and the scope of its needs, but one thing is certain: it’s going to be expensive. In addition to requiring additional employee hours, SDN requires a deep analysis to determine necessary hardware updates. Layered on top of that is the purchase price of the SDN solutions themselves. Over time, costs can easily run into the hundreds of thousands of dollars, stretching even the most generous of federal IT budgets.
Run some numbers before embarking on a full-scale migration. Ascertain whether or not the cost of managing SDN is less than the costs incurred managing a manual network environment. Include the cost of set-up time and the processes that are being automated in this analysis. If the numbers work in SDN’s favor, you have a good bottom-line reason for taking the SDN plunge.
Understand the risks so you can be prepared for them
Even after you’ve decided to move forward, know that SDN migrations can be fraught with risk. Therefore, they should not be done in a wholesale, “big bang” type of manner, but accomplished using a piecemeal, highly thoughtful approach. This makes the migration easier while helping to preserve uptime as much as possible.
Even so, sooner or later changes on the core network will inevitably impact certain services, such as switching or routing. When this happens, there will be some downtime -- unavoidable when one turns their network over to SDN and begins to rely on changes being made without human intervention. Knowing this in advance, however, can help you plan for it, making it easier to navigate these bumps in the road heading to greater agility and nimbleness.
Adopt additional best practices to optimize your SDN
There are other best practices you should consider adopting after you’ve begun implementing SDN in your agency. Teams should get certified on SDN or get functional training on how to work in an SDN environment, which is much different than what most professionals are accustomed to managing. Establish a protocol of backing up policies on a regular basis, as opposed to just backing up configurations of network devices. Employ monitoring as an ongoing discipline, continuously and automatically analyzing your network for potential issues that could prove harmful so that you can react to them quickly.
Above all, do not be afraid to experiment. Understand that mistakes will inevitably occur, and you will probably fail at least some of the time. Learn from these times. Improve upon processes. Make things better.
After all, that’s how we achieve progress. Perhaps for you, that progress will include a future network that is more agile, secure, reliable, and software-defined.
By Joe Kim, Executive Vice President, Engineering and Global Chief Technology Officer, SolarWinds
Related Blog Posts
