Here’s why you really need SDN

Last week, I wrote about the confused approach many of the largest network vendors are taking to software-defined networking (SDN). In most cases, the issue is that the shift to SDN from their current hardware-focused business would cause them real economic pain, not an aversion to the fundamental benefits for customers of freeing networks from specialty hardware.

Another reason to be wary of SDN is that it can’t scale performance as well as hardware can, says Ali Kafel, director of product marketing at networking vendor Enterasys. He suggests that you simply can’t switch and route data as well on a general-purpose processor as you can on the purpose-built ASICs used in today’s specialty networking gear. For the most part, he’s absolutely correct: A general-purpose x86 processor will never perform as well as an ASIC designed specifically for the task, especially if you throw a layer of virtualization in between.

However, focusing on performance alone misses the point of what SDN is all about. We saw that same misdirection in the early days of server virtualization, where hardware server vendors — fearful of reduced server sales — said the performance of general-purpose servers running multiple VMs wouldn’t be able to adequately scale their performance versus running a single (nonvirtualized) instance. Yet today, server virtualization is extremely common, and you don’t hear about scalability problems.

In any event, such complaints don’t address SDN’s rationale. Flexibility is the special sauce SDN and the virtualization that usually powers it can deliver — especially when you consider the needs of the cloud. To see why, consider what kind of services a typical medium-size business might require if it were to make the jump to the cloud.

Let’s say you’re the infrastructure manager for a medium-size manufacturing company. You have a headquarters site, two satellite plants, and a few smaller sales offices scattered around the country. Over the last few years, you’ve shifted away from mainframe-based applications, and now almost all your infrastructure is virtualized on an x86 platform. As you’re preparing the budget for your next major technology refresh, your CIO demands that you consider moving your infrastructure to the cloud.

Whether you’re comfortable with the idea of having someone else store and run your business’s crown jewels, it’s clear that the technology exists to do it — and to do it well. As a quick rule of thumb: If you can virtualize a workload on your premise, you can probably run it in the cloud without much trouble. The only real technical challenge then becomes assuring adequate connectivity to your cloud-based workloads.

In this example, your company probably already has a fairly well-developed WAN to support reliable access from the satellite plants and offices back to the headquarters. That might typically involve MPLS or ELAN with an Internet-based VPN mesh as a backup. That’s not too complicated to implement using traditional network gear (a couple correctly sized routers and a firewall at each site will do the job nicely), but how would you implement that if your infrastructure is running in the cloud? After all, you may still have that WAN gear at your premises, but what exactly does it talk to in the cloud?

Most cloud service providers looking for this kind of business have made it relatively easy to buy a direct connection into your virtualized cloud environment from your premises. Getting your cloud-based network environment linked up to your MPLS or ELAN isn’t out of the question. However, what if you want to keep the same connectivity model you had previously?

Your hosting provider isn’t likely to have the flexibility to take on the role of your premises’ routers and firewalls in its own gear. Instead, it might suggest that you implement your own — right there inside your cloud, like all your other systems. With your own “cloud firewall” or “cloud router,” you can implement whatever level of security and redundancy you want without needing the cloud provider to do anything for you or to stretch to implement multitenancy on its own hardware-based networking gear.

Will that virtualized, software-based firewall or router be slower or take more processing horsepower than one that’s running on purpose-built ASICs? Absolutely. But it will also be yours, free for you to configure and manage as you see fit — as if you had your own hardware firewall sitting in the cloud provider’s data center. In fact, you could even stretch your infrastructure across to a completely different cloud provider for site redundancy without asking either vendor to do anything unusual — all because you can implement your Layer 3 services in software rather than depending on compatible hardware at each provider.

It’s this flexibility that will drive SDN to the forefront of enterprise and cloud networking. However, Enterasys’s Kafel is correct in that Enterasys, Cisco, and others don’t have to fear that all their hardware networking business will disappear — the ASIC-based gear definitely still has a role. Where peak performance weighs more heavily than flexibility (service provider networks, storage networking, and so on), hardware-based switching and routing will still rule the roost.

Any vendor that ignores what SDN can deliver risks not being able to provide the flexibility and mobility that IT customers will undoubtedly ask for as the cloud matures.

This article, “Here’s why you really need SDN,” originally appeared at InfoWorld.com. Read more of Matt Prigge’s Information Overload blog and follow the latest developments in storage at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.