When planning an SD-WAN deployment, some best practices include evaluating your business model, testing the product and establishing vendor support guidelines.
Interest in software-defined WAN is surging, as seen in SD-WAN market growth and industry conferences.
Research firms IDC and IHS Markit estimated SD-WAN revenue will reach $5.25 billion and $4.4 billion in 2023, respectively. While those numbers are eye-catching, enterprise IT teams are more concerned about SD-WAN best practices, how to troubleshoot the technology and whether it will make their networks more complex.
Many of those SD-WAN concerns emerged last week at the ONUG Fall 2019 conference in New York City. Users and panelists expressed apprehension about SD-WAN security, holistic visibility and multi-cloud integration. And, despite SD-WAN's growing popularity, risk aversion is still a major deployment deterrent, according to Neil Danilowicz, principal architect at Versa Networks.
"The biggest inhibitor for SD-WAN is it's new," Danilowicz said. When network engineers learn SD-WAN uses traffic steering that varies from traditional methods, they question whether the technology will work and how they'll troubleshoot it, he said. Those concerns then dovetail into the challenge of SD-WAN complexity.
Ironically, the complexity that arises with SD-WAN is a result of the flexibility SD-WAN offers. IT teams can set certain policies to handle their traffic in specific ways, Danilowicz said, but this means they need to write policies that are "intelligent to both the network and the application."
The complexity comes when teams need to ensure both the network and applications talk the same language so the network layer can meet application requirements, he added. This is where integrated analytics can help detect any disconnects or issues.
SD-WAN best practices before deployment
Neil Danilowicz
As IT teams conquer their risk aversion and start to research SD-WAN technology, they should devise a game plan for implementation. Danilowicz mentioned three SD-WAN best practices to consider in the planning stage.
Understand your business model. Enterprises that are evaluating SD-WAN should first nail down their business model and goals, Danilowicz said. While these goals vary among organizations, IT teams should assess how mission-critical applications play with the network, gauge budget and long-term costs, and pinpoint any security concerns. Each organization is different and will have its own objectives, and different vendor options might be better suited to those requirements.
"Each SD-WAN vendor has its niche, with some doing certain things better than others," Danilowicz said. "Knowing what your needs are helps you phrase the questions."
John Fruehe
Another important component in this step is the integration between the existing WAN and the new SD-WAN architecture, according to John Fruehe, an independent analyst. Because most teams don't approach SD-WAN from a greenfield environment, they need to understand how the new technology will work with legacy management tools, connectivity and security.
"It's always important to understand the business model when engaging in a new project, but most SD-WANs are actually replacing or overlaying an existing WAN circuit, not a new project," Fruehe said.
Test the SD-WAN service. Testing is often overlooked, but it's a vital part of any SD-WAN deployment, especially long before the implementation process.
SD-WAN is not a product where you go to the vendor, get a flashy presentation and the sales guy shows you where to sign the dotted line.
Neil DanilowiczPrincipal architect, Versa Networks
"SD-WAN is not a product where you go to the vendor, get a flashy presentation and the sales guy shows you where to sign the dotted line," Danilowicz said. "This takes a lot of preparation and testing to figure out whether or not it meets your needs."
Fruehe likened the process to a test drive when buying a new car. A potential buyer tries out the various features, gauges the performance and speed, and assesses steering and handling.
"You wouldn't buy a car unless you had some time behind the wheel on a test drive, and SD-WANs are infinitely more complex than cars," Fruehe said. "While testing will take a lot of time and effort, it can save tons of time down the road."
An in-depth testing process can take potential customers up to six months, Danilowicz said, and might involve tests for quality of service, availability, scalability, management and failover. The more work that teams do in the testing phase, the easier it is after implementation because they've already established SD-WAN best practices to handle any issues that may arise.
Look for vendor partnership. When looking for an SD-WAN vendor, enterprises can choose from do-it-yourself (DIY) SD-WAN and managed SD-WAN. A crucial part of the search is to ensure the vendor or managed service provider (MSP) offers good, reliable support. Ultimately, the choice correlates to the organization's individual requirements, resources and preferences.
"You want to look at how the partnership with your service provider is going to work," Danilowicz said. "There are a bunch of managed services that can help and aid the journey into SD-WAN. Whether you go with DIY, a complete managed service or a hybrid model, it's really up to the end customer."
With DIY SD-WAN deployments, customers oversee provisioning, ongoing management and troubleshooting. As such, they should look for vendors that offer reliable customer support. In the case of MSP partnerships, IT teams don't deal directly with the SD-WAN vendor that provides the actual technology. Instead, they trust their MSP to choose the vendor, provision the service and help with continued maintenance.
"Many SMBs -- and even some larger companies -- will turn to MSPs or their existing telecom carriers for SD-WAN," Fruehe said. "In reality, in these situations, those companies are basically at the mercy of the provider."
In such cases, businesses need to choose an MSP that they can trust to receive the capabilities and support they require.
Neil Danilowicz
John Fruehe
