The problem with disruptive network technologies is that they are sort of…well…disruptive. The issue occurs when you’re trying to institute a disruptive network technology and it forces your system to go offline – something many corporate IT networks simply can’t afford to let happen. The reason many companies opt for tried and tested technology over brand new, disruptive technology is that a company adopting new tech is likely to be the “guinea pig” that other companies considering it will use as their benchmark.
There are many things that can potentially go wrong, meaning that fixing it is usually not as easy as finding where it went wrong elsewhere and applying the fix to the issue. In any sort of disruptive network technology, the best way to go about implementing it is to use a small test-case before it gets rolled out across the entire enterprise network. That way minor bugs can be caught and rectified before they have a chance to propagate and create problems in a live network. So how does a company adopt a disruptive network technology to play nice with existing architecture?
A Safe Way to Switch to SDN’s
SDX Central defines Software-Defined Networking (SDN) as a means of separating control logic to a location that is off the device, usually utilizing software to control that logic. The key to implementing an SDN solution across an enterprise-wide network rests heavily on having the right diagnostics in place. Since this is software-based, having a place to log and view the network performance is necessary to sort out where the kinks are happening. Different methods of implementation will differ by company.
Having open standards implemented ensures that even client locations can successfully interface with the SDN. Another useful tactic is “canarying” traffic – using a private subnet running parallel to existing interfaces in order to transition the traffic that isn’t as critical to the organization. Like a coal miner’s canary, this subnet would report issues with the traffic flow before the SDN is implemented on critical network traffic connections. Most importantly, having a backup in place is priceless since no one can be sure what may happen.
Rolling Out SD-WAN on a Network
Cisco states that Software-Defined WAN (SD-WAN) is a methodology of managing a wide-area network utilizing software. In a nutshell, it takes SDN’s benefits and applies it to the running and administration of a WAN. Before SD-WAN is adopted across the entire network, a handful of specific ‘test-sites’ should be used to gauge the response. All the issues that may occur both critical and unimportant, should be logged since it offers insight into what you may encounter at other sites. With increased scale and complexity come increased problems. SD-WAN relies on a main controller that is then linked to subsidiary sites.
This main controller usually needs a system administrator to run it and supervise rollouts of outdated technology to new routers that can be used alongside SD-WAN. Theoretically, once the installation finishes the network should just as functional as the original, albeit with a lot of improvements in management and reliability. A test period where the SD-WAN network runs in tandem with the original network architecture is useful for working out problems in the system while a backup is still present to take the load.
IBN and New Paradigms in Networking
While SDN and SD-WAN offer agile solutions, Intent-Based Networking (IBN) is one of the newest and most potentially disruptive technologies around. Noction notes that Cisco’s presentation on IBN talked about its ability to learn, evolve, and adapt to changing network conditions, creating a network that is agile as well as ‘smart’. Being so new, IBN is a technology that will require a lot of patience, understanding, and know how to adapt well. The disruption to an enterprise can potentially be massive since the system needs to be revamped in order to run IBN. Systems would need to be ported over to an application-centric interface (ACI) and be running operating systems that are compatible with IBN. IBN is a lot more than just a simple reworking of network architecture. Its integration can affect all parts of an organization and an enterprise intending to adopt it needs to be ready for its impact at all levels.
Network Function Virtualization for Corporate Needs
Metaswitch notes that Network Function Virtualization (NFV) is a method of turning individual components of the network into fully realized software components virtualized on a network infrastructure. Both NFV and SDN create software-based approaches to networking and remove the dependence on physical hardware. This has a lot of connotations when it comes to cloud computing as seamless integration with the cloud for processing and storage is simplified through a software interface. Multiple IT teams would be required to implement NFV at an enterprise level and clear communication between these teams is a necessity to ensure that the system is functional. Lifecycle management, as well as centralized policies governing data, need to be taken into account before adoption. Existing application migration will similarly need due care to ensure that all dependencies and data are accountable and accessible.
Adopting Disruptive Technology should be a Needs Case
It’s always exciting to see the potential of new technology and how it can be applied to an existing business, but the truth of the matter is that even though these technologies are brilliant and can theoretically aid an enterprise to reach its full potential, the level of disruption that they can cause while being instituted is a serious concern. If a company can see the benefits clearly and are willing to take the chance of a disruption slowing their business practice, then it’s a good idea to adopt this cutting-edge technology. If the benefits aren’t immediately obvious, then it may be a better idea to simply stick with what works.
