The consensus in the networking world is SDN is the future of enterprise infrastructures. Yet, most IT shops have...
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
shied away from software-defined networking in the past few years. The reason for the hesitation hinges on the belief that SDN implementation doesn't offer enough benefits today, when compared with the amount of time and effort required to migrate away from legacy architectures.
This view is rapidly changing, however. There are currently plenty of use cases where SDN can be deployed to make meaningful strides in the way networks and applications can be deployed, managed and simplified. That means right now is the time to start planning for your eventual end-to-end SDN architecture that is coming in two to three years. In this article, we're going help you get started by looking at four key steps that lay the groundwork for your future SDN implementation.
Step 1: Develop a realistic migration plan
While it would be nice to completely rip and replace -- or even spin up SDN parallel to your legacy production network -- that's probably not feasible for most organizations, considering the high upfront capital expenditures involved. Instead, a more likely scenario involves strategically migrating a legacy network to SDN. This can be accomplished with two popular SDN migration methods:
- The first is the divide-and-conquer method. With this, you segment parts of the network and focus on making sections of it SDN-aware. You then tie the legacy network together with the software-defined network so the two play nicely together. This method is beneficial because you get to design and deploy SDN exactly as you see fit. The downside is you can't gain the true benefits of SDN until the entire migration is complete, because it's not deployed in an end-to-end manner.
- A second popular SDN migration plan is to create a virtualized SDN network overlay across legacy network hardware and software. Using this method, you can achieve many of the end-to-end SDN benefits early in the migration process. You are limited in your deployment options, however, since you rely on the virtualization capabilities of legacy components that may not provide the flexibility you need.
Step 2: Understand where SDN can provide value today
The biggest challenge network architects face in terms of an SDN rollout is how to move from a traditional network deployment to SDN architecture with the smallest effect on end users and on the IT budget. In order to do this, you must understand the immediate value SDN can provide.
Most IT departments have concluded that SD-WAN deployments have the biggest effect due to their intelligent routing capabilities, which can significantly lower WAN connectivity costs and easily integrate with traditional network deployments throughout the rest of the network. Software-defined data centers are another logical starting point where benefits can be immediately realized. This is especially true in terms of the automated provisioning of complex distributed applications.
Step 3: Think about the bigger network interoperability picture
Once you've found your "quick win" in terms of an SDN implementation starting place, you should take a step back and look at the network as a whole. Keep in mind that the overall goal for SDN aims to create a seamless, end-to-end infrastructure that results in automated network agility. In other words, you don't want to manage multiple disparate SDN segments on your infrastructure. And despite the buzz around SDN open standards, open source, open hardware and open APIs, you still need to be cognizant of how each part of the network will interoperate at a software-defined level.
Step 4: Evaluate your current network for SDN readiness
There are some parts of your enterprise network infrastructure -- such as your campus LAN -- where an SDN implementation still doesn't make a whole lot of sense in 2017. It stands to reason, however, that the value will eventually emerge over the next few years as other parts of the network are migrated to the new architecture. That's why it's important to take a snapshot of your currently installed network hardware and software to see what is SDN-capable today.
And depending on your migration path -- either the divide-and-conquer approach or virtual overlay -- you can then determine what SDN capabilities your network hardware and software may already possess. You may be surprised to find that those switches you just purchased -- or plan to purchase -- are indeed SDN-ready.
Bottom line on SDN implementation
An end-to-end SDN migration is not an easy thing to achieve. Software-defined services aren't just a simple evolution. Instead, they are entirely new approaches to how we leverage the network. It used to be that networks were built to blindly transport data from point A to point B without any foresight into what was actually being sent and received.
SDN turns that philosophy upside down to where it is now all about the application and what kind of data is being transported. Because of this, migrating from legacy to software-defined networks can be tricky. That's why it's so important to take a holistic approach to planning SDN migrations to make sure you're not missing anything. A proper plan at the start of your SDN journey will make the process go much more smoothly.
Private clouds need easier SDN deployments
Make sure SDN is right for your organization
Advanced network monitoring and SDN enhance each other