The benefits of SDN or Software Defined Networking has been touted by network professionals across the enterprise and data center for several years now. The new-ish model calls for centralized control across the network and separating the data and control planes for more agile and efficient networks.
While early adopters and super-users have gravitated toward SDN, much of the industry is still taking a measured but steady approach to adoption. In a recent report, IDC predicts that the market will have a compound annual growth rate (CAGR) of 53.9% from 2014 to 2020. This includes physical network infrastructure, control software, SDN applications, and professional services. (Source: IDC).
Using an SDN model allows for critical networking services like automated provisioning, network virtualization, and network programmability. Other SDN benefits include:
What’s next? Across the WAN
Many believe the primary growth engine for SDN in the coming years will come from businesses that decide to leverage the technology across the WAN to branch offices and to the campus network. If you’re evaluating an SDN-migration plan, consider these factors before moving forward.
Outline the core requirements of your network
The good news is moving to a software-defined architecture can be done in a gradual manner. Organizations can get started on SDN by automating pieces of the network environment through virtualization. During virtualization, the IT team needs to first understand and prioritize the core requirements of the network. And, while not all requirements of the starting network may be met in the first phase of the transition, they should be documented. For example, the businesses early migration plan may be focused initially on wireless users, followed by select wired users in a remote office.
Preparing the network
Early on, administrators should determine the potential impacts of a new virtualized model on existing services, and if any gaps exist there should be a backup plan in place. This point seems straightforward, but taking this step upfront can eliminate possible service interruptions, which may hinder the migration effort. Also, administrators need to determine the network service levels needed for the target deployment (i.e. network availability must exceed 99.9% with a fail-safe scheme to revert back to the legacy network). Teams should make a list of applications that will be used for connectivity and continuity checks throughout the transition and consistent testing should be done throughout the process.
Is your hardware compatible?
Whether you’re working with a cloud SDN provider or you’re migrating to the virtualized network on your own, it’s important to consider options that are hardware compatible. Many see OpenFlow as a migration path to SDN-model because it moves network control out of proprietary network switches and into control software that’s open-source and locally managed. With OpenFlow support on switches, for example, during the transition the configured VLANs is tested for reachability and users can be migrated. From there, OpenFlow is enabled for the new subnet by configuring the controller. Finally, testing is done to determine the migration is complete and objectives are met for network performance and reachability.
For most, the question no longer revolves around the pros and cons of an SDN model, but rather how to best make the transition to the network architecture. When done systematically, network virtualization will help to simplify branch office networking and assure optimal application performance. While the migration plan might seem challenging at first, asking the right questions of your cloud provider and committing to a gradual and vetted transition will be more manageable and pay dividends in the long run.