SDN, or Software Defined Networking, was supposed to be the Next Big Thing(tm) in how networks were built and designed. In reality it often creates more problems than it solves, and never really addresses the Business Needs of what it was conceived to accomplish.
SDN FROM POST-CONCEPTION BECAME ALL ABOUT VENDOR LOCK-IN
One of the problems, as others have pointed out, is that SDN from post-conception became all about vendor lock-in. You were tied to their software, which was tied to their hardware, which was tied to their reference designs, methodologies, features, upgrade cycles, and support systems. All that money you would save (hah!) on expensive network engineers suddenly was diverted into a recurring revenue model with a vendor. You wouldn’t actually save any money at all, instead you would hemorrhage cash flow into companies like Cisco.
Another problem was that for most vendors, their “fancy” SDN software was really only about “solving” a very specific problem, or small set of problems that had limited possibilities. Sure your SDN vendor might throw you a web page with more graphs than a demo grafana dashboard, but under the hood it was no better than a bunch of QBASIC GOTO statements to manage the load balancing and traffic predestination of various WAN links.
At the end of the day, none of this really came together to solve real problems other than propping up $vendor’s quarterly balance sheet.
… and then came Whitebox Networking. No, that’s not a vendor, but a term for taking reference hardware designs from companies like Broadcom, slapping on the network operating system of your choice (Cumulus Networks, Free Range Routing, Snaproute, Vyatta, etc.), and walking out the door with extra cash in hand with virtually unlimited capabilities in the equipment you just purchased. No longer are we tied to a specific all-encompassing vendor to meet our organization’s networking requirements in terms of hardware and software.
Okay, so this helped break the nefarious umbilical cord between organizational IT and $vendor, but we still lacked ways to combine network designs and equipment and software and documentation to meet business needs in a way that didn’t take months or years of methodical planning, creating documentation, change windows, etc. only to realize that something was missed and that the needs of the business aren’t really being solved (and done in real-time, for that matter).
INTENT BASED NETWORKING
Enter Intent-Based-Networking, or IBN.
Ohhh look, another markety thing! Shiny!
All <snark></snark> aside, this is what SDN was really designed to do. In theory in this model one designs not the network, but the needs of a service or application and lets the software design or redesign the existing network in realtime to meet that need.
Let that sink in for a bit. Seriously. Go grab a cup of coffee, tea, water, Kentucky bourbon, or whatever tickles your fancy while you think on this.
Let me say it again:
“… in this model one designs not the network, but the needs of a service or application and lets the software design or redesign the existing network in realtime to meet that need.”
So going a bit deeper into the concept here, you might tell your IBN software that you intend to deploy an application (X) using storage resource (Y), any particular Quality of Service or SLA requirements you have, and then the software will reconfigure your mixed-vendor network to create an environment that meets these needs. This is just one example, but it’s an amazingly powerful concept with real promise.
WITH SDN, YOU GET STUCK TRYING TO IMPLEMENT THEIR CRAP
We’ve all heard stuff like this before in IT – tech that seems too good to be true. “This world-changing tech is a paradigm shift that overlays and merges business acumen with network zeitgeist to create synergy of idea and symmetry in execution.” – or something. Blah, blah blah. 12 months later and a few million $ in the hole, nobody is any happier except for the salesmen (sales-women, sales-person, sales-you, so-on) who made comission on your folly. You get stuck trying to implement their crap, and they take off to the airport in their 2nd or 3rd Ferrari to head to Maldives.
… but this time, it seems to be legit. Much like how x86 / x64, the iPhone, Linux, VMware, and to a lesser extent Ubiquiti (with outdoor wireless and UniFi) changed segments of IT in massive ways, Intent Based Networking has actual promise and real customers.
As covered on a recent packetpushers.net podcast, Apstra has a real product to do this NOW. Yes, it’s young technology, but it’s rapidly developing. Other vendors are getting in on this as well; new, hip software companies as well as the usual suspects of traditional vendors. Both have skin in the game of course, and this will be a long ugly battle before the fog rolls off.
Until then, keep brushing up on your python and your cloud certifications. Automation in the network is just the start.