We have all drunk the Kool-Aid. Software-defined networking (SDN), network functions virtualization (NFV), or both will save the world. They decouple us from the shackles of legacy networks to allow a utopia of business-driven requirements to freely flow, delivering value and freeing the network, application, storage, and infrastructure teams to have weekends off and time with their families.
Articles Tagged with SDN
In virtual and cloud environments, network traffic often flows into a virtualization, then back out, forwarded to another device, usually security, before it re-enters the virtual environment. I call this a “sadly defined network,” not software-defined. Many of my colleagues claim that this is not true. They say that an SDN keeps east-west traffic within the hypervisor and that north-south would not need to do this. I disagree. This will happen when bad design is implemented in virtual and physical security. “Ah!” some will say, “this is solved by micro-segmentation,” but that is not always true, either.
Software-defined networking (SDN) is clearly one of the hot items of the tech field at the moment. VMware’s purchase of Nicira precipitated a sea change, leading to today’s plethora of SDN vendors and array of competing technologies. It reminds me the early noughties—the introduction of virtualization, competing hypervisor technology stacks and Unix/Linux Zones*—followed by the scramble of the incumbents as they claimed performance penalties for virtualized operating systems and platforms, followed by spreading FUD about support status and onerous licensing models.
It’s that time again. VMworld 2014 opens in San Francisco on Monday, August 25. With fifty sessions covering network virtualization and security this year, it is clear that VMware is once again pushing software defined networking (SDN) and NSX, and that is as serious about the software defined network as it is about the rest of the data center. Unfortunately, I cannot make the conference this year, but I have perused the session catalog to see what sessions I would attend if I could. These cover a cross section of technical and procedural levels and should be beneficial to network virtualization newbies and veterans alike.
So, in no particular order, let’s start with my ten-ish most interesting SDN sessions. OK, so I couldn’t get it down to ten, and there are a couple more that should have made this list, but “my twenty-seven and three quarters most interesting sessions” doesn’t really cut it.
On April second, Cisco introduced something that seems to make a lot of sense in its new declarative-based, ACI-led world of software-defined networking: a policy mechanism. The blog post about it was pretty straightforward: it included the obligatory nods toward the Internet Engineering Task Force (IETF) and open-source communities, defined the differences between the traditional imperative and the newer Cisco declarative models, and had snazzy graphics. Cisco laid out the core challenge clearly:
For this declarative model to work across a multi-vendor environment, to translate and map policy definition into the infrastructure, there has hitherto been no standard protocol to do that across physical/virtual switches, routers and L4-L7 network services. This vacuum has led to the development of OpFlex, a new open standard recently submitted to the IETF.
Despite all of the rapid innovation and the incredible rate of change in technology, there are some things that you can count on. One of those things is that the transition from hardware to software is a cyclical one, and if you look at any one segment of the market long enough, that becomes apparent. We’ve seen it in the move from mainframes to x86 servers, to virtualized servers, to distributed, scale-out systems. We’ve seen it in the move from terminals to PCs to VDI to EUC and even in the move from legacy storage arrays to software layer, scale-out storage aggregation. Now, we can start to see the SDN market following the same pattern, and one of the leading indicators of that comes from a company called Netronome.