SD-WAN: Build vs. Buy
As interest in the benefits of Software-Defined Wide-Area Networks (SD-WAN) has grown in the past 18 months, we at H.A. see more and more questions from customers about the best way to consume SD-WAN. In this post, I will discuss some of the decision points that may help businesses determine where they fall on the SD-WAN “Buy” vs. “Build” spectrum.
If you need a primer on SD-WAN technology, H.A.’s Jason Bishop wrote a great SD-WAN 101 article previously on this blog.
Early in the emergence of SD-WAN, most people thought of SD-WAN as a thing an enterprise would own. That the enterprise’s architects would research and select an SD-WAN platform and then procure and deploy the components internally (possibly with the help of a VAR). This means the enterprise moves away from service provider lock-in; it gives them the ability to build their own WAN over any network transport. In fact, that’s the exact story most SD-WAN solutions tell. Some even explicitly point out that SD-WAN becomes a good way to strong arm your existing Service Providers (SPs) into lower service rates by reminding them of your ability to ditch them completely and roll your own WAN with whatever low-cost circuits you can get.
As SD-WAN started to come into the marketplace, most traditional WAN providers immediately identified it as a potential threat to their value-add WAN offerings. After all, if SD-WAN provides enterprises the ability to swap underlays (WAN circuits) out at will without impacting the overlays that the business’ data runs over, this puts WAN SPs into a position where their services become a pure race-to-the-bottom to avoid being swapped out at any time.
In response, most SPs and have begun offering a managed SD-WAN solution where they provide customer-premises equipment that provides the SD-WAN functionality over circuits the SP provides (either directly or through their own agreement with a third-party provider).
This got me thinking about the pros and cons of a managed SD-WAN approach versus running your own SD-WAN from an end-user enterprise’s perspective, particularly through the lens of whether managing a WAN (whether traditional or software-defined) is really a “core competency” of any enterprise.
Managed SD-WAN Pros:
- One throat to choke – It’s on the SP to own, manage, and maintain all the transports they may be using for your SD-WAN.
- Speed of deployment – SD-WAN is hot and everyone wants to know how to get there. Taking the “Buy” path and letting someone else own/operate/manage the solution will certainly be one of the fastest ways to leverage SD-WAN benefits with limited retraining of operations staff.
- Insulation from market consolidations – If an enterprise selects a service provider for a managed SD-WANaaS solution and the SD-WAN technology vendor the SP chooses does not survive the inevitable market consolidation, that is the SP’s problem, not the enterprise’s.
- For enterprises with strong strategic partnerships with an SP that previously had difficulty getting circuits into some locales, an SD-WANaaS model may make it easier to keep remote sites “on net” even with no SP-owned/leased transport.
Managed SD-WAN Cons:
- If you are concerned about locking-in with an SP and letting them get more ingrained in your environment, managed SD-WAN is clearly not for you.
- Data Privacy concerns come to mind – recently we’ve seen much less trust in the SP, with many enterprises choosing to encrypt data even over a “private” WAN. Managed SD-WAN and the application-level traffic routing and advanced analytics puts a lot of information into the SP’s hands, and potentially the hands of any actor or agency with hooks into them.
- Pricing – Clearly, service providers’ interest in managed SD-WAN offerings stem from concerns about their existing profits eroding in an age of SD-WANs built out of low-cost broadband connections. Will an SP-managed service hold the same pricing advantages of a self-managed one? I would have my doubts.
On the other hand, a self-managed SD-WAN solution purchased and operated by the enterprise may be a better fit in some cases.
Self-Deployed SD-WAN Pros:
- Flexibility to select exactly the right product for your needs. Each SD-WAN vendor has some unique features and value propositions, and choosing your own SD-WAN vendor allows you to prioritize those features differently than an SP may have.
- Aggressive feature deployment: If a solution has new features in software that matter for your business, you can probably get them deployed quicker if you run your own SD-WAN solution. SPs may be less aggressive with rolling out new features.
- Control: The topology, underlays, and security are completely under control of your business and can be configured however needed.
- Freedom from service providers – much like “cutting the cord” with your home cable, keeping the circuit providers as a commodity service with no value-add makes it easier to swap them out or go in a different direction if a situation or site requires it.
Self-Deployed SD-WAN Cons:
- Product selection: You must select a vendor for your solution. Few, if any, are interoperable so mixing vendors isn’t really a feasible option at this stage. A couple years ago, this was a riskier proposition, but in recent months some market consolidation of the most notable startups (such as Viptela and VeloCloud) have occurred as they are acquired by incumbent IT vendors (such as Cisco and VMware).
- Training: SD-WAN uses newer, sometimes proprietary, encapsulations and routing methods, new terminology, and underlay/overlay concepts. You will need to be comfortable with these topics to reliably manage your own SD-WAN. This may require engineers to be trained or have access to lab environments.
Whether you are interested in building your own SD-WAN or purchasing SD-WAN services from a service provider, the benefits of the technology make it very compelling in today’s IT environment. High Availability works with several vendors of SD-WAN solutions, so contact your account manager today to discuss options and let us help find the solution that best fits your organization.