In software-defined networks, traffic decision making shifts from hardware to software. That brings flexibility but also greater risk.
Software-defined networking fundamentally changes where in the network the action happens. While that might not seem exciting at first, let’s break it down.
In the old world, dumb hardware decided where to route traffic, how to redistribute volume to prevent chokepoints and what to do with malicious actors. Software-defined networking (SDN) initiates a shift, with the network controller wresting power from hardware. That shift enables the network to handle far more volume and complexity– while allowing for greater automation within the network. Growing companies can handle spikes in Web traffic, and innovation can gain traction by accommodating new cloud-based applications, because the network can finally handle it.
At the same time, SDN and network controllers aren’t cure-alls for some of the problems that dumb hardware faced. The network can help navigate traffic flows and govern security, but the physical infrastructure needs to be ready to accommodate these developments as well.
So what are some important considerations when evaluating network controllers? What are some of the unique features and pitfalls that network controllers introduce? Let’s take a look.
In the old days, if you wanted more features and functionality in your network, you needed to buy new devices, rack them up in your data center, configure and add them to your management universe. Conversely, with SDN, you can purchase or source plug-ins that perform all sorts of network activities, including load balancing, firewalling, reverse-proxying, and so on.
This allows for far greater flexibility in the network, and these plug-ins work directly within the network controller and virtual switches on the network, boosting performance and flexibility. Most products are designed to be extensible and integrate well with an open controller. Generally, you can install modules or plug-ins into the network controller to enable additional functionality.
In fact, many controllers, offer programmatic interfaces, including the following:
Many network controllers are also open source, which means they have open source code under the hood. This code is written and contributed to by a community of network professionals and developers. POX and Beacon are good examples of open source network controllers.
Various providers offer other network controllers to enable special integration among network hardware and software. Both open source and proprietary network controllers have their role.
Open source controllers ensure a standards-based network, particularly when they are used with network devices from multiple vendors. They often have a vibrant community behind them, enhancing the technology as the state of the SDN art advances. On the other hand, proprietary network controllers working on vendor-specific hardware often offer increased traffic speeds and capabilities. They also come with a support infrastructure for when things go haywire, as they eventually will.
While SDN creates a centralized point of management, it also creates a centralized point of risk. Simple clustering and replicating virtual machines and states across the wire don’t transcend hardware in an SDN environment. Network switches maintain a hard state. Most clustering and replication systems do not account for the state of individual ports—they seek to roll over the entire system into an “up” state. That’s acceptable for servers and most workloads, but not when it comes to continuous streams of data, which switches generally handle.
Good network controllers account for the state of switches into a transactional replication system. This ensures that, in the event of a fault, one can replicate instances of the network controller while also maintaining a consistent switch state—without taking down the network—so that the network switches can establish a consensus.
But fault tolerance also includes the controller’s ability to continually manage all the devices on the software-defined network after a failover or a fail-back procedure. It's important to know how well these fault-tolerance procedures scale beyond the corporate campus and to a cloud-based data center with hundreds of thousands of customers and thousands of hosted network configurations. Can your network controller vendor keep pace with that scale?
As you consider network controllers from various vendors, a key differentiator is how serviceable they are. Often the logs from a controller will be a first source to consult when troubleshooting network issues. Are the logs easy to find? Can they be shipped to central logging facilities, where an existing network monitoring environment can capture events as they happen and proceed through alerting workflows? Another servicing concern is how easy it is to patch the network controller for feature enhancements as well as to repair or mitigate security flaws. Since the network controller is a key role, most controllers can patch the role without bringing it down.
While centralized management through a network controller opens up the possibilities for managing your network, there are, of course, caveats. As the network controller takes over more of the decision making in the environment, risks abound.
There are a couple of points to make here: