By Paul Parker, SolarWinds Federal & National Government Chief Technologist
Here is an interesting article from my colleague Joe Kim, in which he explores the impact of software defined networking on agency networks.
It’s ironic, but true: software-defined networking (SDN) is tough to define. Perhaps that’s why agency network administrators are still trying to wrap their minds around the concept of SDN, despite its known benefits. They know that 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?
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. 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 SDN is appropriate for your agency.
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 to deliver faster, more reliable, and overall better quality of service.
Monitoring the network during testing will provide some insight into whether 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.
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 federal IT budgets.
Run some numbers before embarking on a full-scale migration. Ascertain whether 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.
Find the full article on our partner DLT’s blog Technically Speaking.