Until recently, Software-defined networking SDN was both a buzzword and the subject of some discord in the IT community. Even after becoming nearly mainstream by being bundled into VMware vCenter as VMware NSX and other platforms as a platform middleware function, many IT professionals are still unsure how to define and then best approach it. At the end of the day, the real question is: “Is SDN really a necessity in my organization, and do I even need to worry about it?”
Although the definition can sometimes be contextual, software-defined networking really boils down to software-infrastructure actuation as applied to networking. Network configuration under software control. Numerous companies positioned to take advantage of these capabilities using their pre-existing software.
"Today, hardly a week passes without a significant announcement of a collaboration between a CSP and a SD-WAN solution provider"
From its inception, the idea behind SDN was for it to be a set of APIs and services that would allow policy-based configuration and power advanced controllers. With enough north- and south-bound APIs systems could be integrated to autonomously manage change. This is where the difficulty of defining SDN comes in. Developers are more than likely aware of what SDN is, but can disagree on implementation depending on how they came to it: via Cisco ACI or VMware NSX. For administrators, however, SDN might seem more like a tightly-integrated package solution (or part of a package solution) that’s essentially a middleware layer.
There’s also still some SDN fear, uncertainty, and doubt coming out of open source committees, commercial controllers, and platform vendors targeted at competitors, which creates headaches for IT organizations who want to explore SDN as a way to create a more innovative and efficient businesses.
How to Approach SDN
Arguably, one of the biggest hurdles is that many IT professionals simply don’t know how to begin approaching an SDN deployment. SDN can be very powerful, which, of course, means it can be very complicated—the implementation is not trivial. In the case of packaged applications, if you have the right gear and set it up according to configuration guides, you have the chance to be successful. However, if you area more configuration-focused enterprise technologist and expect that SDN is as simple as a configuration exercise, you will be disappointed because implementation is actually a development exercise. With this in mind, SDN’s complexity, both perceived and real, is an issue.
Risk is another hurdle to consider: you can and should implement SDN bit by bit on a network, but sooner or later, there will be changes on the core network and it will start to in turn affect core services—core switches, core routing, etc. When that happens, you start betting your enterprise on SDN technology. In some organizations where nimbleness and agility are a business requirement and the organization is willing to accept potential downtime to achieve better overall operational efficiency, this is a good strategy. However, for more risk-averse companies where downtime spells disaster, SDN is a bit scary because changes are being made without a human being to manage them.
As with many new technologies, cost can be a source of concern as well—SDN can be expensive. It’s not so much adopting a particular controller or software appliance, but that SDN-compatible hardware requires, at a minimum, a deep analysis to determine necessary hardware updates. In some instances, these upgrades are required on purpose by vendors to support additional sales.
Although the ability to test SDN is often unavailable in a smaller company, when available, it is important to evaluate a product in a test environment that closely simulates production. During testing, you should look for two basic measures that always apply in IT, and are doubly important here:
• Cost efficiency: If the number of hours in managing an SDN environment is less than it was to do it manually, that’s a good indicator that SDN is right for your organization. This should include set-up time as well as what’s being automated.
• Service quality: One of the main reasons for implementing SDN is the removal of human error and the creation of more repeatable processes. It’s also far more powerful and can make changes faster than people can. This means you will want to monitor network performance with an eye towards tagging what is affected by SDN and what is not, as well as more closely tracking availability and uptime. If there’s more uptime with systems that are managed by SDN, that’s a good sign that it might be appropriate for your organization.
A bonus measure for SDN is if it can accelerate business processes during testing—if you observe business units are getting their initiatives done more quickly, and if IT seems to be less of a barrier while relying on SDN technologies, it may grease the wheels for a full-scale implementation.
Portrait of SDN in Enterprises Today
If you’re already looking for SDN solutions, you’re probably already part of a progressive, dev-focused organization with resources dedicated to experimenting with new technology. Alternatively, you may be a part of an organization where being able to quickly adapt networks is a core part of business—such as at a carrier or ISP. Carriers and ISPs have effectively operated SDN networks for a decade, although through proprietary technology, the virtual routing structure inside these networks is configured with software that makes physical changes. Many organizations leveraging containers or elastic provisioning also can leverage SDN to great benefit.
Interestingly, even if you don’t fit any of the molds described above, some companies are already getting SDN with something else they have, without even knowing it. If your organization is a large user of VMware, NSX is probably getting tucked into maintenance renewal invoices with the expectation it will facilitate something else, such as accelerating VMware vRealize network changes.
So, if none of the above scenarios fit yours, does that mean SDN is not right for your organization? Possibly. SDN is generally not a fit for organizations that are too small to dedicate teams to focus on learning and understanding its intricacies and how to make it work reliably. If SDN is implemented via a consulting team, but the administration team is expected to manage and troubleshoot it when it breaks despite having no SDN-related knowledge, it will end in a headache for everyone. In other words, it’s a best practice not to implement SDN if you can’t dedicate resources to it.
Getting There: Best Practices for Working with SDN
• Backup policies on a regular basis: Today, we back up configurations of physical network devices at the time of change; with SDN, the same thing is happening except with policies. Figure out how to troubleshoot in the virtual realm of SDN configurations with the same skill that you have to troubleshoot standard text-based configuration, documents, and physical devices.
• Get certified or do functional training: SDN is different enough, and if you’re not already a programmer, networking expert, or familiar with APIs, you’ll need plenty of education. Many vendors offer this for free.
• Make mistakes and experiment: Because this is a new technology, mistakes will happen as your team and organization adapts to policy-enabled configuration and management. The ability to fail fast with SDN is high because the controller is taking care of the bulk of administration tasks that you would previously have been responsible for. Think about policies, making bulk changes across the environment, and cascading changes. If there’s no experimentation, there’s no demystification of the technology.
• Employ monitoring as a discipline: Basic monitoring principles apply in the testing and implementation phases of SDN adoption. As mentioned above, SDN-compatible hardware requires deep analysis to determine hardware update needs, and the controversies around the cost of SDN can be put to rest once monitoring data can show the need for (or lack of) hardware updates.
Nowhere to Hide
You may already have a strong opinion against SDN and sound reasoning to back it up, and it’s true that some organizations are not a fit for this technology. On the other hand, it’s also true that large organizations with resources to dedicate can certainly see cost savings and increased service quality, and in the right conditions, may even call SDN a necessity for their businesses. Regardless, SDN is increasingly baked into the tools and services we already rely on. Expect it to become an even more hotly contested topic as containers, virtualization, and cloud technology increase in usage and demand network software actuation for success.