For a while, I tuned right out when someone mentioned SDN. The term has become so ubiquitous and cliché that it’s lost almost all meaning to me, as a network engineer. But finally, after what seems like years, SDN is starting to come out of the trough of disillusionment and into the realm of productivity.
Cisco is making a play for the access layer with software defined access, the SD-WAN market is maturing into a permanent part of the networking paradigm, several vendors have well-established platforms for the software defined data center, and network automation is becoming just another part of the network engineer’s toolbox.
SDN, though still a little annoying to hear sometimes, is finally starting to take on a practical form apart from vendor hype and marketecture.
Initially, the idea of a software defined network was about being vendor agnostic, though individual vendors have been developing their own SDN controllers for use with their own devices. And since SDN seems to mean something different to everyone, I’m going to stick with a super generic definition and say that SDN is the abstraction of a network in software, whether that be the control plane or management plane.
The conversation about SDN has centered on organizations with huge networks and their associated problems. The discussion often failed to address that most networks are much smaller than our favorite webscale companies and have different problems to solve.
Your local hospital may have 12 locations, 9,000 end-users, and two small data centers, and though this is by no means a small mom-and-pop shop, networks of this size just don’t have the infrastructure and hardware refresh cycle of today’s webscale companies. And I believe that these types of networks with a few hundred or a few thousand network devices make up most of the network infrastructure engineers are working on today.
Think about your latest hardware refresh project. How much of the network was replaced? Just the access layer? Maybe only the edge routers? And how often do you actually replace your core switches?
Most networks are more of a hybrid infrastructure with both SDN components and legacy devices.
This is why I see a vendor agnostic management overlay as the bridge between purely legacy networks and pure SDN networks. Most organizations are operating a mix of some legacy gear that must be managed one device at a time and some SDN equipment that takes advantage of open APIs and SDN controllers.
For example, an organization may implement SDN solutions like Cisco ACI or VMware NSX in their data center, an SD-WAN solution for their branch offices, and embrace network automation for pulling information from devices. But still present are the hundreds of switches that can’t be replaced in this year’s budget cycle, last year’s firewalls that haven’t been fully depreciated yet, and the five-year-old core switches that, frankly, are still doing just fine.
So how can we take advantage of the benefits of SDN, specifically programmatic management of disparate devices, in this kind of hybrid infrastructure?
This is why I love the idea of an overlay configuration management tool that can accommodate multiple vendors, multiple platforms, via multiple interfaces. It’s a practical and relevant application of software defined networking that gives network engineers real value today.
I’m not talking about changing the underlying network stack, but the programmatic management of legacy devices as well as the newest platforms.
I’m talking about having visibility and management of devices that support only SNMP but also newer devices that support open APIs.
I’m talking about going to one interface to have visibility into my firewalls, switches, and routers regardless of vendor and regardless of if they’re last year’s model or today’s latest and greatest.
I’m talking about being able to view and manage my Cisco ACI environment in the very same interface that I use to manage my core switches, firewalls, and routers.
And then the next step would be to automate workflows altogether. A centralized management overlay can automatically kick off event-driven diagnostics, for example, via SNMP and RESTful APIs. In this way, a bridge solution can provide more than just visibility and programmatic management but an entire workflow of automated tasks that exist in software and not only in a network engineer’s mind.
This is part of software defined networking, and this is how it can be introduced into real networks with hardware lifecycles, several vendors, and project plans that can span several years.
SDN may be cliché, but a highly tunable, mature, and vendor agnostic network programmability overlay certainly is not.