SD-WAN is often touted as the first network-focused, software-defined technology to break into the enterprise.
However, while it comes along with a host of whiz-bang technologies and the hope of a future end-to-end SDN future, it's important to remember its true benefit: saving you money. (See SDN Means 'Speed Da Network' for Cloud Provider Navisite.)
Whether you have already deployed SD-WAN -- or are planning to do so soon -- there are several best practices that can help ensure that when your IT department deploys SD-WAN, it's done correctly and your enterprises can actually see the cost savings the technology offers. (See Cisco, VMware Battling for SD-WAN Supremacy – Report .)
Let's first think about a typical enterprise networking infrastructure.
Your organization's WAN is often one of the most expensive line items in the overall IT budget. For remote locations that are business-critical, and thus require reliable connectivity to applications and data hosted within the corporate data center or private cloud, leased line connectivity has traditionally been the go-to option.
Most often that meant signing an expensive long-term contract for either Metro-Ethernet or MPLS services. These traditional services are neither quick to deploy or cheap to operate.
This is precisely where SD-WAN can step in. (See Cloud Pushing SD-WAN Market to $1.6B by 2021 – Report.)
The idea behind SD-WAN is that it can intelligently and automatically determine the optimal path -- given two or more choices -- for specific types or classes of traffic. This means you can reduce or potentially eliminate expensive, leased-line services in favor of cheaper and more readily available broadband Internet connectivity.
The key is to understand what traffic is considered mission critical to the business and then use that information when configuring policy for your SD-WAN deployment. To make SD-WAN a bit easier to understand, let's use an example of how SD-WAN can save you money.A typical enterprise infrastructure
Let's say your company consists of a corporate headquarters that houses critical applications and data to ten remote sites of moderate size around the country. Some of the applications are sensitive to latency and jitter. Each remote site also connects back to an IP-based communications server for voice connectivity. Lastly, all Internet traffic must be first routed to the corporate headquarters for security purposes.
When calculating bandwidth requirements for the critical applications -- in addition to all other network usage -- it was determined that each location must connect to the corporate headquarters with a 50 Mbps MPLS circuit. Additionally, for redundancy purposes, each location is also provisioned with a 50 Mbps broadband Internet connection.
However, this Internet link is only used if that MPLS circuit fails. If that happens, the network will re-route all traffic across a VPN tunnel over the Internet.
This example is a typical network design for enterprise-class remote sites around the world. However, not only is it expensive, it's also wasteful. It's expensive since IT must not only pay for a 50 Mbps MPLS private connection, but also for a 50 Mbps broadband link that is rarely, if ever, used.
Yet, instead of taking advantage of these clear shortcomings of current designs when migrating to an SD-WAN architecture, this is often where SD-WAN deployments fail to achieve optimal cost savings benefit.
Too often, network architects will continue to use the same WAN connectivity options already deployed. They then simply add SD-WAN load balancing functionality on top of it. This is completely acceptable if the additional bandwidth is needed. But if it's not, then your organization gains nothing from a cost savings perspective.
Instead, traffic should be analyzed to determine what data flows are critical -- and only then redesign the WAN with SD-WAN capabilities.Re-engineering the network
In our example, let's say that we identify five applications, including voice, which are considered mission-critical to the business. Monitoring these data flows using tools such as Netflow and layer 7 traffic monitoring, we determine that maximum throughput requirements for each of the remote sites is 10 Mbps in either direction. Calculating expected growth, it's determined that critical traffic for remote sites is likely not to exceed 20 Mbps over the next three years.
Armed with this information, the IT vendor relations department should work to re-negotiate MPLS contracts down to reduce them from 50 to 20 Mbps. This can be a tremendous cost savings for organizations with multiple remote locations.
Now that we have calculated and properly right-sized our leased lines for mission-critical data, SD-WAN can re-route all other traffic that can ride across the lower-cost 50 Mbps broadband link that previously went unused.
Additionally, in the event of an MPLS failure, mission-critical data can still ride across the larger 50 Mbps broadband connection and Quality of Service (QoS) policies will drop lower-prioritized traffic accordingly if congestion begins to occur. The reverse is also true in the event of a broadband link failure.Getting more out of SD-WAN
There is also the possibility that some remote sites can operate across two or more SD-WAN managed broadband links without any need for expensive leased line connectivity. Business-grade Internet has come a long way and many IT departments are finding that they can run latency-sensitive data flows over broadband without any issue.
SD-WAN can monitor when congestion, latency or jitter is occurring on one ISP link and reroute latency-sensitive flows across the other. While this design may not be for everyone, in many remote-site situations it provides a WAN service that rivals traditional leased line quality at a fraction of the cost.
If you are running -- or intend to run -- an SD-WAN architecture, make sure that you put plenty of thought into how you can leverage the technology to lower costs. If you're not careful, you'll end up with a fancy new toy for network engineers and the same expensive service provider fees. Neither of which is beneficial to the overall business.
Instead, seek out the true value of SD-WAN which is lowering the line item expense of leased WAN connectivity.Related posts:
- Automated Service Provisioning: Getting It Right
- Serverless Computing: Why You Should Wait
- Microsoft's Azure Stack Is Useful but Not for Everyone
- Intent-Based Networking: What Does It Mean for Your Cloud?