A world without WANs
Is the SD-WAN promise a requirement the market is yet to understand, or is it a technology looking, in vain, for a problem?
When I started an SDN business in 2015 with the view to bringing the most immediately-applicable, software-defined networking services to South Africa, SDN was on the early incline of the hype cycle. "SD-WAN" was a new term and barely understood.
The promise was one of fully-programmable networks that could intelligently route your traffic; for example, via satellite or terrestrial links depending on the weather conditions in each geography.
What emerged as the initial driving force away from MPLS VPNs was less exciting: essentially, the traditional feeds and speeds, more bandwidth at a lower cost.
Most adopters of SD-WAN in SA are motivated by their ability to replace expensive MPLS links with much cheaper, high-capacity broadband connections while maintaining a basic level of network inter-connectivity and security.
The promises of programmability, centralised control and granular traffic management are all still there, but they are secondary in the majority of WAN-conversion decisions at this stage.
The bottom line is that network capability currently, possibly for the first time, exceeds the requirements of most customers.
What's driving the evolution of the WAN today has more to do with the adoption of cloud applications and the exponential increase of overall data due to applications such as business intelligence and 'big' data analysis (O365, AWS, Salesforce.com, Microsoft Power BI, SAP Hana).
So, is the SD-WAN promise a requirement the market is yet to understand, or is it maybe a technology looking, in vain, for a problem? Are centralised control, bandwidth management and programmability features most companies actually need or simply expensive novelties?
My core assumption when launching an SDN business was that they are the former.... but I've come to believe that I was wrong, at least in the medium- to long-term.
The bottom line is that network capability currently, possibly for the first time, exceeds the requirements of most customers. The cost of bandwidth has reduced so significantly that most customers don't actually need more bandwidth than they can afford. Taking advantage of bandwidth abundance is a business necessity but the question of whether one still needs a WAN is far less certain.
If I were to build a company with 10 or 20 branches today, either locally or globally, would I put a WAN (of any description) in place? Probably not. Desktop applications are all in the cloud. There is certainly no need to host a mail server or a webserver of any description. Branches talk to applications, not to each other. What exactly would the point of a WAN be?
So, assuming we can get one or more cheap, reasonably-reliable broadband connections per site, and can sort out some basic security to protect end-users from external threats and each other, and that we can do this all at a fraction of the cost, hassle or maintenance overhead required to run a "WAN" be it SD-WAN or MPLS, then, it seems, WAN-less is the obvious option.
In addition to the above, you might want to consider how to optimise the performance of applications hosted over 100-metres away from your branch offices, but this is easily done today without negating the abovementioned advantages.
Simple steps can also be taken to overcome perceived obstacles; like using simple, affordable technologies to make your inhouse applications available via the Internet.
It appears to me there aren't any strong reasons left to support the implementation of a WAN.
Brett Steingo is co-founder and COO of Accelerate Networks. As a representative of Aryaka and Aritari in South Africa, Accelerate Networks claims to have been the first company to introduce SD-WAN services to SA in 2014 and today specialises in application performance improvement for cloud, VOIP and global network services. Steingo has been involved in various telecom start-ups and has also spent more than 10 years in senior roles at leading organisations, including MTN and IS.