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.
Opendaylight lacking support
Q: Are there standards?
For now. Openflow is the standard for allowing SDN controller software to control a switch, regardless of whether that switch is physical or virtual. OpenvSwitch is a critical project that has become a standard reference implementation of a server-spanning vSwitch.
Opendaylight was a standard and at one point had broad industry support. Then Opendaylight started producing working code and looked like it was going to actually work. As soon as it became more than a PR exercise the big names promptly wet themselves in terror and all their shiny new stuff stopped interoperating with Opendaylight.
Hmmm. I wonder why.
Q: Are we growing in the dark?
Not at all! Everyone involved in SDN is perfectly aware of what they – and everyone else – is doing. They are all trying to kill each other off via lock-in and monopoly with extreme prejudice and the bloodbath that is about to occur in the networking sector will make the whole software defined storage wars seems like a Care Bears picnic by comparison.
At this point, SDN and NFV – though in their infancy – have been around for long enough that any seeming chaos in the industry is anything but. It is coldly calculated backstabbing, betrayal, politics, threats, partnerships, and blackmail.
Everyone is jockeying for position and the name of the game is to create optics that say you're open, friendly and supportive of your customers' business needs while quietly working to kill off anyone that threatens your lock-in. Even the new players in the market are playing by this rulebook.
Q: What are the particular requirements
For SDN you need an SDN controller, a switch that is compatible with that controller. Cisco, Juniper and others will gladly sell you such things.
For those interested in the "open" side of SDN this usually means Openflow based switches and Opendaylight as your SDN controller. In practice, SDN usually means Cumulus or Pica8-based switches, but there are plenty of other switches that support Openflow.
Q: How do service and performance levels change? Isn't hardware is always faster than a software-based thing?
Cisco – and every other proprietary networking vendor on the planet – would really like you to know that the best networking is clearly done in hardware. Their hardware. Preferably managed by their software. To be perfectly clear: with the exception of some fringe workloads that push even the best of the best to the redline, this whole "better in hardware" thing is rubbish.
NFV works just fine when provided by VMs. It even works fine at ridiculously high network throughput. We could argue latency, but the beauty of NFV is that you can try before you buy. Of course, if you try, you'll probably spend a lot less when you buy, so if you like your switch vendor don't give these newfangled things a try, hmm?
My first introduction to SDN was an early Juniper Contrail setup working in tandem with Puppet and Openstack. Push one button and you had database servers on two sites, set up for replication, with multiple layers of application servers, front-end web servers, load balancers, firewalls, security layers, access control lists, and WAN optimisation all spawned and ready in under 30 seconds.
You could move any element around the network, across sites — it didn't matter, the networking Just Worked. It was impressive.
I have since seen this reproduced on Dell switches running Cumulus Networks' switch operating system, married to Opendaylight's SDN controller connected to Openstack Neutron. The "open" demo included backups, DR and monitoring pre-configured as part of the service spawn.
SDN and NFV are important parts of my Software Defined Infrastructure concept. Indeed, what's on the table today can get us quite close.
An all-hardware approach may be theoretically more efficient than all these layers of abstraction, but that efficiency doesn't really matter all that much when we simply don't use the full processing power or capabilities of our switches, routers, servers and other data centre equipment as it is.
I argue – and apparently a whole lot of people with money agree – that a few percentage points of efficiency is a small price to pay for the level of automation and ease of use SDN and NFV enable. ®