By Scott M. Fulton, III
When you listen to one vendor for any extended length of time, you begin to get the impression that the world really does revolve around its own axis. Yes, I speak as the veteran of countless Microsoft conferences; and yes, several of my friends with penguin hats are saying, “I told you so”. Last week’s VMworld conference can give one the feeling that VMware not only invented software definition in networking (which it tried to distinguish from “SDN”) but is also its sole practitioner.
“The reality is… businesses are stuck in silos today,” announced VMware CTO Ben Fathi at the start of last week’s Day 2 keynotes. “They want to be able to run their traditional enterprise applications, but they also want to enable their developers to build these new cloud-native applications. IT wants control over the infrastructure, and developers want to go around IT. They go directly to the cloud sometimes, because they don’t want to wait for the infrastructure to be provisioned. Everybody wants instant, elastic access; developers want self-service, but IT also wants control. They want security. They want to make sure the infrastructure is in compliance when they deliver it.”
All that led to the company’s general manager for software-defined data centers, Raghu Raghuram, making his grand pronouncement that his company’s NSX overlay network “is the only architecture that can resolve the conflicts that Ben talked about”. The “only” one.
In SDN (yes, including VMware), an overlay network is the part of the network that is executed on x86 servers instead of with virtual switches and routers. It is the part of the physical network that is completely absorbed into the realm of processors and memory. From a software perspective, management and orchestration components link to an overlay network by means of an API. (VMware doesn’t use the term “orchestration,” but it is using, more and more, the term “OpenStack,” so at some point it should become inevitable.)
What the overlay network does, and how it goes about it, is determined exclusively by its vendor. The explicit purpose of VMware’s NSX is to engineer a network completely in software for supporting VMware virtual machines. NSX connects downstream to ESXi hypervisors that are running virtual switches, although KVM and Xen are also officially supported. But the clear purpose of NSX is to pave the way for VMware’s virtualization infrastructure as the most convenient option.
Last year, Alcatel-Lucent spun off an entire company, called Nuage Networks (pronounced “new-AHge,” the French for “cloud,” not like the Yanni music) for the purpose of proffering its own SDN infrastructure. Nuage architecture implements an overlay network; and like NSX, Nuage architecture is determined by Nuage. It “exposes” its services “northbound,” as network architects say, by way of VPNs.
But it, too, has a vendor-specific purpose, or at least the intent of keeping things in the family: enabling Nuage software components, such as its “consumable” VPN endpoints (“SDVPN”) as well as Alcatel-Lucent physical service routers at the network’s edge, such as its venerable 7750s, as the most convenient option.
In a YouTube video published in June, A-L principal solutions architect Dave Twinam first distinguished his product from a typical “SDN”. (Saying what you’re not always seems to be Step 1.) From there, he goes on to make the case for why the objective of SDN should not be to grease the wheels for VMs but to expedite communications and the processes surrounding it.
“Obviously you have virtualization capabilities in terms of VLANs, for example, which is something we’ve been using for many, many years,” Twinam says. “But the challenge of that is still very much static and manual in nature. There can be some automation in the form of scripting, but really, most of the scripting is still calling out CLI commands, which is just automating a manual process. But fundamentally, it typically takes a long time. What we find to be a commonplace scenario for a lot of our clients is, they can turn up a virtual machine in a matter of minutes, but to get it actually connected to the network may actually take weeks or months, and that’s because there are multiple steps that are required.”
Nuage’s solution to this dilemma, continues Twinam, is a policy-based engine which can apply architectural decisions to the overlay network by way of a template. This way, like placing a stone in a river, the changes flow through and the network is re-routed through those changes in ways the physical network could never be.
Jarrett Neil Ridlinghafer
Founder & CEO/CTO
Synapse Synergy Group, Inc.