The content below is taken from the original (Tips for building SD-WANs), to continue reading please visit the site. Remember to respect the Author & Copyright.
The substantially high cost of MPLS circuits ($200-$400/Mbps/month) compared to easily deployed, lower cost broadband Internet (with a price tag of $1/Mbps/month) has triggered a shift in enterprise architectures to the software defined WAN. SD-WAN provides the flexibility to choose the most optimal transport and dynamically steer traffic over a mix of MPLS circuits, the public Internet, or even wireless LTE circuits.
The access transport selection depends on a variety of factors, including the type of application, traffic profile, security requirements, QoS and network loss and latency. When implemented correctly, SD-WAN truly has significant advantages: Faster service deployment, increased flexibility, unified management and improved application performance, to name a few. But, while familiarity about SD-WAN has increased over the last year, a survey by Silver Peak and IDG shows only 27% of small- to mid-sized enterprises have shifted to SD-WAN.
What’s more, the majority of SD-WAN deployments today are relatively static in nature, with little to no adaptive switching of the access layer. The first wave of SD-WAN deployments does allow the flexibility to choose from available transports, but policy-based traffic segregation is relatively static. As with any technological evolution, the migration to SD-WAN will occur in phases.
If you’re considering the shift to SD-WAN, consider the following to maximize the benefits and to ensure a smooth transition:
* Plan ahead. Choose between backhauling traffic from branch offices to the data center via Internet VPN or MPLS circuits, on the one hand, and locally breaking out traffic from the branch office through upstream Internet Service Providers (ISPs), on the other. If your application demands strict SLA and faster resolution upon failure, then tromboning traffic through dedicated circuits to a data center, in spite of higher latency, might be beneficial.
Under such circumstances, a distributed data center model would yield more value than a centralized architecture. The architectural options are unlimited and vary from one organization to another. Before choosing the deployment model that’s right for your organization, baseline the network for application performance and optimal user experience. For example, evaluate the network performance for real-time applications like VoIP and video before choosing the right transit. Organizations typically design their network to rely on more than one ISP for redundancy. Choose your upstream ISPs by monitoring for outages and frequent failures, then be sure to validate your new architecture before deploying it.
* Don’t lose visibility. Part of that validation should include having visibility into proprietary algorithms employed by SD-WANs to calculate the optimal path that will vary with each vendor. These algorithms are dynamic in nature, which means the best path can constantly change depending on the algorithm and parameters like network loss, latency, available network bandwidth, traffic profile and Quality of Service (QoS).
Irrespective of what the path is, it is important to have end-to-end visibility of the underlay network and the overlay application delivery perspective to be able to accurately troubleshoot and triage faults. Invest in a network monitoring platform that can not only provide visibility into internal MPLS and VPN networks, but also the public Internet, while maintaining application level correlation. Consider supplementing your SD-WAN vendor’s view of network measurements to get a reliable and unbiased view that can also help mitigate risk.
* Evaluate risk. Relying completely on the Internet for WAN connectivity comes with certain risks. Partial or complete service disruption is not uncommon when connectivity to an entire region is shut down for political or economic reasons. For example, a few years ago Egypt shut off the Internet creating an “Internet island” that affected traffic going to and from the country. In such circumstances, relying completely on the Internet can create havoc in service delivery and disrupt user experience. Manage risk by understanding what it means to completely rely on the Internet for your WAN connectivity. Identify and monitor ISP outages caused by routing inefficiencies or leaks or complete Internet blackouts caused by political policies.
* Focus on the end user. While SD-WAN is all about the network, don’t lose focus on the end user. End-user experience is perhaps the most critical component to ensuring successful service delivery. See how changes in network behavior affect application delivery as experienced by the end user, especially as they move between various wired and wireless networks across your campuses. You can do this using data monitored directly from end user devices, enhancing the view of your network from more centralized locations.
There is no doubt SD-WAN migration has inertia today. But MPLS is not going away overnight. As with every technology adoption process, the WAN is going to evolve in phases. Keep these recommendations in mind as your WAN evolves to ensure an efficient and effective cloud and Internet-centric architecture.