As a DevOps engineer who has implemented multiple software-defined networks (SDNs), I know that many engineers are ambivalent about them. Some are not convinced they’re needed anymore, in light of container technology. Consequently, there are three key questions about SDNs: What exactly are they? How does it work? Do I need one? The answers to these questions are important to the future of any platform or system an SDN integrates with.
What is an SDN?
So, to answer the first question, 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.
Available since the advent of virtual networking, SDNs rely on the same technology that you already have in your infrastructures. However, they add a layer of automatic configuration management on top of those technologies.
Since they use the technology that you already have, SDNs are naturally good at crossing over many types of hardware and hosting platforms. This is arguably the best part about using an SDN. You can connect multiple different cloud providers, private collocations, data centres and everything in between, in any combination and, generally, it will just work.
How Does an SDN Work?
It’s important to understand that the SDNs function 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.
Before picking one of these modes of operation over the other, carefully consider the pros and cons of each. 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.
This mode processes each individual packet, which has an advantage and disadvantage. 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.
Specifically when it comes to performance and efficiency, engineers will gain several significant advantages over the userland networking modes by using kernel mode networking. 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.
The key issue 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.
When SDNs make sense
There are three measurable advantages that are making SDNs more attractive to enterprises of all sizes: reducing complexity, reducing costs and accelerating your network and development operation teams.
Complexity is reduced by the fact that network settings are automatically configured and propagated 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.
An SDN costs less by virtue of the fact that it serves 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.
By reducing complexity and cost, 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.
SDNs emerge victorious
Despite some engineers’ mixed feelings, SDNs have proven their ongoing viability. For all of the current SDN technologies, there are two things that define their success: they enable fully automatic configuration, and that enables teams to move quickly. There’s no need for a middleman in a connected network like this, and there is greater agility. Smaller companies are using SDNs so their IT teams can home in on what’s most important to them, leaving the mundane and time-consuming tasks to SDN’s automation capabilities. That gives them a competitive advantage over enterprises that aren’t moving as fast.
Christian Saide, development operations and software engineer, NS1
Image Credit: Flex