National Instruments SD-WAN case study: Bandwidth up 1,500%
In this SD-WAN case study, learn how Cisco Viptela technology transformed one enterprise WAN for the better -- from decreased costs to increased performance.
It's a nearly universal challenge facing enterprise WAN managers: Do more with less.
Luis Castillo, senior global network engineering manager at National Instruments (NI) -- an automated testing and measurement systems manufacturer based in Austin, Texas -- faced the same obstacle, causing frustration for Castillo's team and, as a result, NI employees.
"Typically, there's pressure to reduce WAN spend by about 2% year over year, but demand increases by 10% to 20% every year," Castillo said. "The numbers don't add up."
And the users suffered. With 88 sites worldwide, NI's mission-critical applications worked slowly for employees, if at all. Software releases from headquarters failed to reach some branch sites for hours. Frustrations ran high. So, as early as 2010, Castillo's team began looking for a way to use less expensive bandwidth in a more efficient way. They tested early software-defined WAN (SD-WAN) products -- hoping to offload some MPLS connectivity to inexpensive broadband links -- but found the technology lacked the necessary maturity for a large-scale deployment.
In 2016, NI revisited SD-WAN, evaluating 28 different platforms and ultimately selecting technology from Viptela, now a part of Cisco, for a proof of concept. But getting financial approval from NI's upper management required some intensive number crunching.
"SD-WAN is not cheap," Castillo said. His team convinced corporate leadership to fund the project by committing to savings against its WAN portfolio, essentially promising short-term ROI.
The gambit paid off -- and then some. In the first full year of SD-WAN deployment alone, NI's MPLS spending decreased by 40% -- from $1.5 million to around $900,000. In 2019, NI slashed that figure by an additional $100,000. Meanwhile, Castillo reported that bandwidth increased 1,500%, with software updates that once took eight hours to push across the WAN finishing in as little as 10 minutes.
In its third year of SD-WAN deployment, National Instruments prepares to phase out MPLS, a connectivity link used in traditional WAN architecture.
Initially, NI aimed to use SD-WAN-enabled broadband connectivity to merely reduce its dependence on a single MPLS provider, potentially diversifying with less expensive, regional MPLS contracts. But the SD-WAN implementation presented Castillo -- a 25-year networking veteran -- with a plot twist he didn't anticipate.
As much as it makes me uncomfortable, the data shows we don't need MPLS anymore.
Luis CastilloSenior global network engineering manager, National Instruments
"As much as it makes me uncomfortable, the data shows we don't need MPLS anymore," he said. "It causes more outages than anything else."
NI now plans to eventually phase MPLS out of its network entirely, relying on forward error correction and packet duplication features for voice traffic and other applications that are particularly sensitive to jitter and packet loss.
SD-WAN case study: Deployment advice
While Castillo urged other organizations to jump into SD-WAN "with both feet," he cautioned them to do their homework first.
"It's not an easy project," he said. "You do need a lot of engineering work behind it."
To optimize zero-touch deployment capabilities, for example -- a common SD-WAN selling point -- organizations must thoughtfully and rigorously engineer their internal standards and templates, Castillo added. Otherwise, they risk making each site's deployment a unique "snowflake," thus undercutting the benefits of the SD-WAN model.
"We had some very contentious conversations as we worked to standardize the process correctly and juggle tradeoffs," he said. "It's very easy to paint yourself into a corner and over- or underengineer something."
Because NI front-loaded time, effort and resources into designing and architecting its SD-WAN upfront, with the help of Cisco Services, Castillo said the actual implementation abstracted more network complexity than even he anticipated. While a team of nine once managed 1,000 routers individually, two people now manage them collectively via a policy-driven, centralized management console. The remaining team members are now free to focus on "more exciting things," such as Kubernetes and the cloud.
"It takes a lot of engineering work, but it's worth it," Castillo said. "We saved more money, got better performance and solved more problems than we ever expected. It's been hugely, hugely successful."
