Software-defined networking has been the subject of some discord in the IT community. Developers are more than likely aware of what SDN is, but can disagree on implementation depending on how they came to it: via Cisco (News - Alert) 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.
How to Approach SDN
One of the biggest hurdles is that many IT professionals don’t know how to begin approaching an SDN deployment. In the case of packaged applications, if you have the right gear and configure according to guides, you can achieve success.
However, if you expect that SDN is as simple as a configuration exercise, you will be disappointed. 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 should implement SDN bit by bit on a network. But eventually, there will be changes on the network that will start to affect core services (switches and routing). When that happens, you start betting your enterprise on SDN technology. In organizations where agility is a business requirement and the organization is willing to accept potential downtime to improve operational efficiency, this is a good strategy – not so much for risk-averse companies where downtime spells disaster.
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, look for two basic but critical measures:
- Cost efficiency: SDN is right for your organization if the number of hours in managing the environment are less than the manual job – this includes set-up time as well as what’s being automated.
- Service quality: SDN is responsible for 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, meaning that the need to monitor network performance and uptime is important. If there’s more uptime with SDN-managed systems, that’s a good sign that it might be appropriate for your organization.
Portrait of SDN in Enterprises Today
If you’re already looking for SDN solutions, you’re probably part of a progressive, dev-focused organization. Alternatively, you may be part of a carrier or ISP, where being able to quickly adapt networks is core to your business; or an organization leveraging containers or elastic provisioning.
Even if you don’t fit any of the molds described above, you may be getting SDN tucked into maintenance renewal invoices with the expectation it will facilitate something else, such as accelerating VMware vRealize network changes.
If none of the above scenarios fit yours, SDN may not be right for your organization. Your company may be too small to dedicate teams to focus on understanding SDN’s intricacies and how to make it work reliably.
Best Practices for Working with SDN
- Back up 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. There’s room to fail fast with SDN. Think about policies, making bulk changes across the environment, and cascading changes, and experiment to demystify.
- Employ monitoring as a discipline. 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
Although some organizations are not a fit for SDN, some larger 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.
Edited by Erik Linask