SDN's dream: Use what you've got, not what you're promised
Hardware acceleration – busted
Is hardware turning soft? Yes, if you listen to IT vendors. Companies such as Oracle are investing in Software Defined Networking (SDN) — turning features that were once hardware into apps or part of the networking layer or running as apps on servers.
I've recently written about the problems and promises of SDN and find the subject raises a number of questions that demand greater exploration by someone – anyone – other than networking vendors.
Let's start by examining the basic understanding of SDN.
There is some confusion about SDN's value and purpose that might be due to the fact that some pretty basic duties of SDN are neglected in this description.
If you get a real SDN nerd involved they'll probably tell you that the question is actually asking about Network Function Virtualisation (NFV), not SDN. When SDN was first hyped to everyone, NFV wasn't a separate buzzword. It was simply seen as an inevitable extension of SDN, and many people still see it that way.
Increasingly, however, the two are being split as vendors try to carve out niches for themselves and backroom politics plays a bigger role in this increasingly lucrative market.
Yes, the end game for SDN is (sort of) the ability to consume network services such as apps in an app store. This is where NFV comes in to play and in a lot of ways NFV can be seen as the goal of SDN.
The really critical part of SDN, however, has nothing to do with NFV. The critical part of SDN is actually the ability to make all the things on your network know where all the other things on your network are, even though what is where on your network – or even what is on your network – might be changing hundreds of times a second.
Oh, and SDN aims to do that using the cheapest possible hardware, and software that will be priced just enough below the cost of Cisco's offerings that "open" SDN is an enticing way to go. "Open" in this case meaning adherence to protocols not ruled by Cisco, and where companies owning relevant patents agree not to extort money too overtly.
That's all a very large and important part of SDN. NFV is more about what you can do with your fancy rapid reconverging network once you've built it. This brings us to the first question in the list.
Q: If network functions that were once hardware are turned into apps that means you now have to manage these once hard assets as software ... how do you do that? Is anybody doing this (who)?
This is a bit involved. I need to break this up into physical SDN and NFV. Let's do SDN first.
To explain who's who in SDN I need to break this down into two "types" of physical SDN software. For no other reason than reader familiarity I am going to call the two types "VMware" and "integrated". VMware's NSX is the standard-bearer for VMware-type SDN solutions while "integrated" solutions are either proprietary solution from switch vendors or open source solutions that integrate with open switches.
VMware's approach to SDN mostly leaves the switches to sort out layer 2 connectivity themselves and focuses on creating an infrastructure for the "apps" portion of the equation. It does this with layer 3 devices such as tunnels, VLANs and some layer 2 extensibility tricks.
Unfortunately, that means that if you want a resilient, adaptable responsive layer 2 network for NSX to live on top of you, you need to build one yourself. Oh, and you can forget about integrating too deeply with other hypervisors, containerisation setups, physicalisation setups or what-have-you.
While VMware's take on SDN can include others, it's a mind-wrenching nightmare to actually make go.
So if you want to play this game with VMware be prepared to set up your own switch fabric using either legacy post-STP fabric protocols like SPB or TRILL, or to set up a layer 2 SDN fabric so you can run your VMware layer 3 SDN on top of it. VMware-style solutions assume everything is virtualised and treat switches as "dumb".
Integrated SDN solutions are a lot less exclusively virtual. Workloads can live on bare-metal boxes and be directly attached to switches, or inside containers as well as in hypervisors. Networking for and or all of these is handled from the same place and in the same way.
This is a more "true" SDN, in the physical infrastructure sense, than VMware-style solutions. Integrated SDN solutions are about automating the infrastructure, regardless of what's using that infrastructure. They treat switches as "smart", and try to make use of the smarts in the switch as much as possible.
Don't forget that Nokia now owns Nuage, and we have no idea how that is going to play out.
All of these are SDN controller projects. They are software that makes compatible switches do things. They are not, of themselves, NFV projects, and thus there are no "app store" like features or functionality.
Here, things get interesting. VMware doesn't really have an "app store" worthy of the name for VM images or networking services. Don't expect Amazon, Azure or even Docker-like push button deployment. VMware will give you all the tools you need to build that for yourself, but you need to assemble it and fill it with services.
Microsoft is in many ways ahead of VMware. While Microsoft's SDN networking support is primitive at best, they do have the Azure Pack. This provides an app store-like experience for consuming services on your own network that surpasses anything VMware has to offer. In every other way, however, VMware has Microsoft beat.
Openstack, however, crushes both of them. Openstack integrates with virtually all SDN controller software out there and provides fantastic NFV functionality via Neutron. Oh, and Openstack supports multiple hypervisors.