Not all networking professionals agree on the merits of software-defined networks (SDNs), particularly in light of today’s containerized systems. From my perspective as a DevOps engineer with experience implementing many SDNs, I find that organizations tend to have three questions about SDNs. First is: What, precisely, is an SDN? Next, how does it work? And last, do we need one? The answers to these questions have significant implications for the future of any platform or system SDNs are integrated with.
What SDN Is All About
Let’s start with a definition of what an SDN is: a network configuration management tool that is specifically designed to implement a fully interconnected network among your various services and hosts. When using an SDN, every one of the services and/or hosts will be directly linked with all other services and hosts without the use of a middleman. This design decision is the key that makes an SDN stand apart from standard VPNs. Standard VPNs generally rely on various middlemen to connect two or more fully segregated networks together in a point-to-point fashion.
SDNs rely on the same technology that you already have in your infrastructures, but they add a layer of automatic configuration management on top of those technologies. SDNs are inherently good at crossing over many types of hardware and hosting platforms because they use the same technology that you currently use. This is arguably the best part about using an SDN. You can connect multiple different cloud providers, private collocations, data centers and everything in between, in any combination and, generally, it will just work.
The Workings of an SDN
It’s important to understand, when thinking about how SDNs function, that the process runs on each host participating in the network. SDNs can be configured in one of two different modes of operation, depending on the choice of technology and its configuration. The first mode is in kernel networking, which relies entirely on in-kernel networking technologies like vxlan or clever use of routing tables. The second mode is userland networking, which relies on using a TUN/TAP-like device to facilitate the network communication through a userland-based process.
Each of these modes of operation has its pros and cons, which should be carefully considered before picking one over the other. One thing that needs to be called out: neither mode of operation is particularly performant or efficient when compared to fully hardware-backed networking. That's not to say they cannot support the majority of use cases, but if you need 10 Gbit networking among all of your hosts, you may not want to use an SDN. However, if that is your use case, you are unlikely to be looking at using an SDN at all and probably already have the specialized hardware and teams required to support that volume of network.
Management and Storage
The real heart of the matter is how an SDN stores and manages configuration. Most SDNs use CoreOS’s Etcd or Hashicorp’s Consul, but a few technologies have proprietary stores built in to facilitate the same function. This key/value store is how an SDN manages to add, remove and update networking configuration on the fly and then propagate those changes to the rest of the network, in near-real time.
The pro and the con of userland mode networking is that it processes each individual packet. The advantage here comes from being able to manipulate those packets in many more ways that are not available in the kernel. The disadvantage is the large number of context switches that each packet will go through to successfully traverse the network.
By using kernel mode networking, engineers will gain several significant advantages over the userland networking modes, specifically when talking about performance and efficiency. Since it relies entirely on in-kernel networking, there are very few extra context switches for each packet traversing your network, and it uses hardened C code to manipulate and handle those packets. The tradeoff, though, is that there is more reliance on the backend network and, specifically, the kernels being used. For instance, if you need network encryption, your kernel will likely require the ability to handle and work with IPSEC.
Use Cases for an SDN
There are three tangible benefits that make SDNs increasingly attractive to enterprises of all sizes: lowering costs, simplifying configuration and accelerating your network and development operation teams.
Lowering costs: An SDN reduces costs just by serving the same function as networking hardware. Most SDN technologies are fully open source, so they don’t incur any kind of licensing fees and allow for easy manipulation if you find there is a feature that is missing or doesn’t quite work the way you want it to.
Simplifying configuration: Complexity is reduced by the automatic configuration and propagation of network settings across the entirety of the network it is managing. This eliminates the need to reconfigure switches and routers as new hosts or services are added, updated and removed. They are also far easier to keep up to date and hotfix than their hardware counterparts. I am sure every reader has had to manage a switch or router upgrade and then witnessed the woes of what can happen during those upgrades. An SDN is just a software upgrade and can usually be done in place and rolled back at the first sign of a problem.
Acceleration: When cost and complexity are reduced, network and development operations teams can move faster. Since an SDN will automatically configure the networking for the new server that was just created, your network teams will no longer need to worry about making sure that all the tedious configurations needed are in place. Your development operations teams can directly integrate the key/value stores with their larger configuration management pipelines. This allows them to manage the more important parts of designing and building new architectures to help solve real problems, instead of worrying about which IP address is assigned to which server.
The Clear Advantage
Two factors make all of the SDN technologies that currently exist worthwhile. The first is that they allow for fully automatic configuration, which then enables teams to move swiftly. Second, this creates the kind of connected network that fosters agility by eliminating the middleman. Slower-moving enterprises are finding themselves at a disadvantage to small and mid-sized organizations that use SDNs to let their teams focus on what’s most important to them.