- Software-defined networking (SDN) is a massive, all-encompassing concept which spans campus, data center, WAN, and carrier backbone networks (pretty much every type of networking infrastructure imaginable) and is being touted by some as capable of solving nearly every networking issue that has plagued us for the last 20 years; and yes, it does make coffee in the morning for you (no, not really).
- Eventually, SDN may do most of the things claimed, but getting there will take a long time and some IT fundamentals and best practices will remain critical moving forward.
The OpenFlow protocol and (more recently) SDN have been discussed and put forth as solutions to complex, hierarchical, legacy architectures that were built up over years to solve the complex performance and management needs of enterprises and service providers alike. Yes, the technology for each type of deployment was different (MPLS vs. OSPF vs. multicast, etc.), based on various criteria, but regardless of the technology, each vertical or segment executed on best practices learned over years of (sometimes painful) experience. The result was a set of processes and instructions, if you will, that each IT or production environment team could leverage as they looked to new protocols or ports or architectures to avoid the same pitfalls encountered before. SDN promises to eliminate the need for several of these, but a few still demand strict adherence or consideration.
- SDN and OpenFlow still depend on wired ports, so the network team remains a critical discipline within the enterprise despite ’software’ being in the acronym.
- Mastering network instrumentation and resilience is critical in order to achieve a truly optimized private cloud (or even many variations of the public cloud); in turn, this requires skills mastered by those which had to balance the network ‘on the head of a pin’ due to legacy technology challenges and hierarchical designs.
- Over time, SDN will eliminate a great deal of manual configuration steps, which is where the bulk of errors and user-induced outages occurred, but the multi-vendor SDN world is still quite a ways off.
The bottom line here, though, is that while SDN may be a software play, it IS the network personified; therefore, it depends on both operational network expertise and (perhaps just as important) network development expertise. Carefully consider any SDN solution placed in front of you, evaluate the solution based on the criteria to which you would have (and will continue to have) your network hardware vendor accountable, and please look past the hype to the deployed reference solutions running a specific vendor’s offering before committing to a lengthy deployment cycle which may never yield the results you desire.