Overview
But what does it all mean?
Well - in a nutshell - it means instead of the server guys having to ask the network guys to stretch a new VLAN between datacentres or add / move / change VLANs on a switch port that a server connects to (be it a physical or virtual switch), some middleware (usually referred to as an SDN controller) will work with the hypervisor to change the configuration automatically.
On top of this, a pipe dream of SDN is that event driven (i.e. a threshold is met on CPU usage or NIC bandwidth usage) VM and network route path changes will occur to ensure a high level of performance.
There's really only two use cases in which I see SDN coming to fruition.
1) Managed Service Providers
MSP's are the primary target for SDN.
Providers running the likes of openstack stand to benefit primarily from SDN through automation of configuration.
Furthermore, if setup correctly, you can essentially allow customers to manage their own network provisioning (whether you'd want to or not...).
2) Non-Cloud Enterprise Data Centres (i.e. All On-Prem in Data Centres)
Are you a large enterprise with hundreds of servers and due to poor housekeeping a mess of a network core with a sea of unmappable fibre and copper patching?
If so, SDN probably isn't for you.
SDN isn't a "magic fix" technology that just makes all your existing problems go away.
If your company is in this situation, you obviously have bigger problems including discipline and governance, and that's not likely to change.
In this situation, SDN could actually be a VERY bad thing for you as you'd then have automated insanity and dig yourself into a hole you may never come out of.
In other words, SDN is NOT a solution to a problem that shouldn't exist.
On the other hand, if you're a large enterprise maybe looking at spinning up a new data centre to migrate to, than yes - SDN would definitely be worth looking at.
Done right (with discipline, design and control), you could design and implement an efficient, predictable and autonomous network core and realise all that SDN has to offer.
Having said that, the same thing can be achieved through good network design without SDN.
Now - one thing to bear in mind - the "crazy filter" that you often get from your network engineers in data centre rollout is essentially removed with SDN.
Just because you're running an SDN environment, doesn't mean you can skip vetting of the requirements by the network engineers.
The way I see SDN is that it's a tool that should still be managed by network engineers and provided to them to make their lives easier.
Handing over this level of access to server engineers is scary.
3) Majority Cloud / Minority On-Prem - Maybe
Is it a case of too little too late though for on-prem servers?
As the trend is to currently stick your servers up a remote hosting service like AWS or Azure, for the small amount of remaining on-prem servers that honestly aren't going to be moving around or changing that much, is it worth deploying a whole new architecture when simple good VLAN design and deployment would work fine?
Even if you do a network refresh and purchase all new datacentre switching, would you bother using this technology for a small-scale deployment?
For me, there's two big issues here:
1. Trust
This technology is very new and no one is using it yet.
Think about what it's doing - changing your NETWORK infrastructure configuration automatically.
What if there's a bug in the SDN controller software or in the implementation of the command interpreter or API instructions?
How will you EVER find the fault and what do you do in the mean time?
2. Control
How dynamic is your network REALLY?
Do you honestly have changes occurring THAT regularly that good network design shouldn't just provide your server guys with a network environment that doesn't require reconfiguration regularly anyway?
It comes down to "how big is your environment"?
If you're a mid-level cloud provider running an open-stack platform for your customers, than sure, this will be of interest to you.
Technology Overview (What it SHOULD look like).
Hypervisor Manager
---------------------------
Hypervisor
---------------------------
SDN Controller
---------------------------
SDN Infrastructure
The Technologies
That's the problem - a standard does exist, but everyone seems to be going in a different direction.
Let's deal with the most established components first.
1. Controller or Custom Vendor Middleware
Most companies generally run one or two brands of switch and route infrastructure in their organisation.
At present, you've most likely got one or a few management platforms used to control the configuration, monitor the health and performance and detect faults across this infrastructure.
This is where there is where the first problem of "the new world" of SDN creeps in.
The original idea with SDN was that there was a common language (with OpenFlow being the leader) that a controller would support.
The controller sits between the hyper visor and infrastructure and talks a common language between both to change network infrastructure dynamically as driven by the hyper visor.
All manufacturers should support this language and away you go.
But no - of course not.
SOME vendors do but others insist on using their OWN language or even worse, use an API.
In fact, most do the later and take their existing management platforms and just tack on the API functionality on top.
I personally prefer the idea of OpenFlow a lot more as it levels the playing field and makes it very easy for customers to swap notes and establish which vendor has best implemented the protocol.
While vendors are using API driven configuration expect your platform to suffer due to:
2. Configuration Protocols
The primary language for SDN is OpenFlow.
Think of OpenFlow as SNMP on steroids for data centres.
Using SNMP you can read and write configuration elements across any brand and model of device that supports it using OID values specific to the configuration element you want to change.
It's super light-weight, fast and enables you to perform bulk changes easily and quickly.
OpenFlow is the same thing - a standardised language that it supported (or at least will be) by many vendors and allows a single controller to manage the network infrastructure configuration.
OpenFlow is obviously a different language to SNMP but does a lot of things the same however also has many additions that are data-centre centric such as:
Let's deal with the most established components first.
1. Controller or Custom Vendor Middleware
Most companies generally run one or two brands of switch and route infrastructure in their organisation.
At present, you've most likely got one or a few management platforms used to control the configuration, monitor the health and performance and detect faults across this infrastructure.
This is where there is where the first problem of "the new world" of SDN creeps in.
The original idea with SDN was that there was a common language (with OpenFlow being the leader) that a controller would support.
The controller sits between the hyper visor and infrastructure and talks a common language between both to change network infrastructure dynamically as driven by the hyper visor.
All manufacturers should support this language and away you go.
But no - of course not.
SOME vendors do but others insist on using their OWN language or even worse, use an API.
In fact, most do the later and take their existing management platforms and just tack on the API functionality on top.
I personally prefer the idea of OpenFlow a lot more as it levels the playing field and makes it very easy for customers to swap notes and establish which vendor has best implemented the protocol.
While vendors are using API driven configuration expect your platform to suffer due to:
- Slower development
- Still locked in to one brand of equipment
- Inevitable bugs or missed elements in API.
- No guarantee as to release cycles to address bugs etc.
2. Configuration Protocols
The primary language for SDN is OpenFlow.
Think of OpenFlow as SNMP on steroids for data centres.
Using SNMP you can read and write configuration elements across any brand and model of device that supports it using OID values specific to the configuration element you want to change.
It's super light-weight, fast and enables you to perform bulk changes easily and quickly.
OpenFlow is the same thing - a standardised language that it supported (or at least will be) by many vendors and allows a single controller to manage the network infrastructure configuration.
OpenFlow is obviously a different language to SNMP but does a lot of things the same however also has many additions that are data-centre centric such as:
