Occasionally my job sees me facilitating videoconferences, where groups of technical people get together and discuss common needs, common standards, best practices, and that sort of thing.
Recently one of these conversations turned to Software Defined Networking (SDN), there was some fairly lengthy debate (and a fair amount of disagreement) about what does, and doesn’t constitute an SDN solution. This occurred, even though SDN solutions have been around for some time now. It’s no surprise then, that many in our industry still have a hard time getting a firm grip on what constitutes an SD WAN.
In fact, some Next-Generation firewalls are now enabling just one or two SD WAN features and some refer those devices as SD WAN enabled. So where is the line?
The truth is, there are many variations on what the industry defines as an SD WAN solution, and some of them look very different from others. Each of the three different architecture types has their own advantages and disadvantages.
Within each of the few architecture types, there are individual features that still may or may not be included. So let’s take a few moments to discuss the core features that are typically contained in an SD WAN solution and help you figure out how to choose one that best aligns with your business goals.
First, what are some of the key features that define an SD WAN solution? I’ll provide a list here that certainly isn’t all inclusive. And robust solutions will include ALL of the features listed, and perhaps more.
These are features that (when 3 or more are implemented together) create a solution that might be sold or marketed as an SD WAN solution. Those on the low end (that just barely touch 3 of these features) might NOT be called an SD WAN solution by some. Again, I’m making my own definition here, since I’m not aware of a good, industry wide definition at present. So let’s look at those key features.
Features of SD WAN.
We'll look at the 3 different types of architectures. Please keep in mind, this is my own characterisation, and some may disagree, and prefer to place them into four categories or two.
Got a project? Start a proposal.
I’m just trying to give you a general “bucket” type strategy for sorting out your options. Also keep in mind that when I say “architecture C is generally more expensive and that’s a disadvantage” that’s a broad generalisation, and there may be options within that category that are more affordable than those in category A or B. Again, we’re trying to sort things out here and help you get a broad view of the landscape as it’s shaping up.
These are solutions that, generally speaking implement a few of SD WAN’s core features without trying to be everything to everyone.
You might think of these as SD WAN lite, because often times these often implement fewer of the core features and keep all of the control contained in one (or a few) local appliances. There is no cloud gateway or controller, no cloud analytics or reporting.
These solutions are quite often more affordable, and that obviously will be seen as one of the advantages of these solutions. However the lack of features like deep analytics, or a more polished user interface will dissuade some buyers.
This type of solution makes a lot of sense if you are managing just a few branches and have a single, stable datacenter to host your controller out of, and if you don’t have a lot of dependency on cloud apps.
This architecture is very similar to the on-prem architecture, but often adds a local device or appliance that acts as a cloud gateway. The Cloud gateway acts to enhance the performance of your cloud applications (Amazon’s AWS, or Azure, Google, etc.) by establishing virtual circuits or tunnels to the major cloud providers at startup.
By maintaining these tunnels (out each available internet path) the appliance constantly measures and maintains the best performance for your cloud applications. So you might consider this solution a premium option in comparison to the on-prem solution.
These solutions might offer a management panel and advanced analytics in the cloud as well. Advantages are obvious, the price is still competitive, and your cloud performance is now always going to be as good as it can be (for the connectivity you’re offering it). Another benefit is that these solutions, generally stack more and more of those features we talked about into them.
The disadvantage is that some vendors have pricing models that charge for the cloud bandwidth pushed through this gateway, and adding more features can add cost quickly. Be careful to not chase the shiny new features if your bottom line can’t support it.
Some solutions providers are pairing with global connectivity providers to offer SD WAN solutions that contain everything I described in the “cloud-enhanced” option, as well as any of the MPLS or circuit options you need on a global scale.
These might even include direct circuits into some of those large cloud providers. This allows you to get to those cloud provider networks with the lowest latency and packet loss possible. In these solutions, your cloud traffic will only fail over to Internet paths if one of those MPLS circuits should fail.
This will appeal to those who are heavily invested in cloud applications and must have predictable connectivity into them. The “package buying” will appeal to those who prefer to have a lot of their large contracts consolidated with fewer providers. As we all know, often times, the larger the buy, the bigger the discount. As you can see though, the disadvantage (to some) is implied in that statement. It’s the size of the buy-in.
Well, I hope some of that is becoming clearer now. Your business needs will dictate which of those key features mentioned above mean the most to you and your bottom line.
I suggest taking that list of key features and choosing just how many of those you can (and can’t) live without. Do a little research on the vendors who have done recent activity with your partners, or even (gasp) competitors and try to do some digging.
Find out what those SD WAN customers liked and didn’t like about their experiences. Then take your list of needs and begin your search. That list should help you talk intelligently with your sales teams and, if you keep it handy, should keep you on track as you navigate the demos. Ultimately, you’ll want to use that as a guide to help you buy a system that has the features you need, at a price you can afford.