Sergey Nivens - Fotolia
Software-defined WAN is moving rapidly through the progression of understanding what SD-WAN is to including it...
in the new meaning of wide area network. Eventually, WANs will inherently do all the things SD-WAN does. But in the interim, IT teams must be extra cautious in selecting an SD-WAN vendor and offering -- especially when it comes to network scalability requirements.
In addition to the typical purchasing considerations that include cost per site, security architecture, management and suitability for use cases with direct internet connections, IT teams need to make sure the product will work in their existing network. This includes ensuring the service can deliver value with the connectivity options in place at current locations and ensuring it can support the whole WAN.
The key thing to know is your network requirements may vary. While a given SD-WAN service may work well for other companies, it may not for your own. No substitute exists for comparing your requirements to a reference network of the same scale and a similar use case, and there's no substitute for trialing the service at scale.
Address your network's scalability requirements
In SD-WAN, scale has two primary meanings: the ability to scale up to the needed level of throughput and bandwidth and the number of sites in the network.
Bandwidth considerations are straightforward. Appliances have specific throughput levels or ratings that can range anywhere from sub-10 Mbps to 10 Gbps. The per-site cost is generally much higher -- often at least 10 times more expensive -- for a high-end appliance than for a typical branch appliance, with 100 Mbps to 1 Gbps throughput, for example.
Calculating scalability based on the number of sites can be trickier. Not only do scalability requirements include provisioning sufficient bandwidth for all your sites, but network architecture matters when considering the scale needed to support a large number of branches. Some SD-WAN offerings are designed to spin up a virtual pipe from every site to every other site and maintain it perpetually. That option puts a large burden of VPN management on the service, which grows exponentially with the number of sites.
Other SD-WAN services may also depend on VPNs, but without the need to have each VPN on constantly. For example, the service might allow customers to precalculate some of the necessary operating parameters for the VPNs and instantiate them only when needed for a network session. This option can support far more nodes than the previous design.
Still, other SD-WAN products take a different approach entirely, without big VPN meshes. These employ architectures where the work of supporting the N+1st site is the same as the work of supporting the second site. This design could support even more nodes.
Questions to ask about scale
Because architecture can put hard limits on the number of supportable sites, IT teams need to ask about it. Below are some questions to consider about SD-WAN scalability requirements:
- What is the hard limit on the number of supported sites?
- How many sites can be deployed before performance begins to degrade or become less predictable?
- What is the largest production network the vendor has actually deployed?
Of course, IT teams must ask for references -- preferably in the same vertical industry that will likely have similar workloads and usage patterns -- and follow up with them. The lived experience of a peer organization can be more useful than any review of numbers.
IT teams have to take scale into account for both bandwidth and the number of sites when choosing an SD-WAN option. How big do the SD-WAN boxes -- physical or virtual -- need to be to support the required throughput? How many sites need SD-WAN? If IT teams do their homework with vendors, ask pointed questions about architecture, limits and actual deployments, and find references to evaluate their experiences, they can find the SD-WAN service to meet their needs -- and move into the brave new world of SD-WAN.