This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
3. - What to consider before selecting an SDN platform: Read more in this section
- Operative needs shed light on which SDN platform will work for you
Explore other sections in this guide:
- 1. - Network innovation leads to SDN basics
- 2. - What's necessary in a software-defined network?
- 4. - Quiz your SDN vendor before committing
When shopping for an IT product, we generally focus on the vendor's offering to determine its appropriateness for the organization. But when considering an SDN platform, you need to be able to articulate your specific business and technology needs clearly and with a high level of detail. After all, SDN will generally require a re-architecture that affects the entire IT spectrum.
It's not enough to say, "I want more efficient operations," or, "I wish I could reduce network Opex." Instead, you need to understand your operations thoroughly so you can articulate your challenges to your prospective vendors. To do that, your organization will need to get lead engineers and/or consultants involved since they know IT operations inside out.
It's also important not to make the mistake of using only your network team to tell your organization's story. If your organization is siloed, you must consider building a cross-functional team to paint the most vivid picture of your IT operations. SDN has the potential to bring together folks from the virtualization, server, storage, development and network teams. Building such a cross-functional team might be a culturally challenging step to take, but it's one with a potentially big payoff if those teams work together to integrate each other's functions into IT engineering as a whole. SDN is a good catalyst for breaking down silos.
The reason for all of this internal soul-searching is simple: SDN vendors don't know what you want in most cases, so they are chasing a moving target, hoping to hit an elusive bulls eye. While the buzz around SDN is tremendous, most shops don't quite know why (or even if) they need SDN. Therefore, a potential SDN customer needs to go into vendor discussions armed with specifics. That will force the vendor to respond in kind -- with specifics. From there, a customer can begin to explore the vendor's platform in detail and understand just how it will change their network.
Know the vendor's SDN platform offering
With so many networking vendor products sporting "SDN" branding, a customer must carefully qualify what a vendor's offering can actually do. While this might sound obvious, SDN means different things to different vendors, and all of them are trying to cash in on the hype. A customer must therefore probe deeply under the hood, as there are no safe assumptions when it comes to an SDN product. The marketplace is simply evolving too quickly.
Along with determining what the product does, a customer should also consider what the SDN product does not do. Perhaps discovering the negative is implied in a mandate to discover the positive, but in the case of SDN, determining what a product cannot do is as important. There are several major considerations:
Performance: If your use for SDN anticipates handling tens or hundreds of thousands of flows per second (or even more), you need to be sure the platform you're evaluating has that capability. Hardware switches that rely on OpenFlow are sometimes hamstrung in high-volume data center environments, all depending on what specific operations they are being asked to do. Certainly there are SDN architectures that can handle large data center environments, but the vendor will need to explain how its architecture scales, and you will need to consider how that might impact your existing network.
Dependencies: Does the product you are considering assume something specific about your environment in order for it to deliver as promised? Perhaps the platform can provision application delivery controllers, but only if they are from vendor X. The platform doesn't work with vendor Y. Or maybe you're considering an application that expects you have OpenFlow-capable switches deployed across your environment already. No OpenFlow? No application.
Roadmaps: IT vendors are famous for introducing new features via a roadmap, where truly wonderful feature X will be available in the Q1 of next year (maybe). When it comes to SDN, don't get sucked in by a roadmap promise. Instead, focus on what the product can demonstrably do now. While some vendor roadmaps are fairly safe indicators of what's coming, the SDN market is too volatile to take a roadmap seriously. The SDN market is changing as customers mature in their understanding of what SDN can do and why they might want to deploy it. Vendors are reacting accordingly, which impacts their roadmaps.