printer friendly version

SD-WAN: how and why

Software-defined networking in a wide-area network (SD-WAN) is emerging as a mainstream technology and is seeing increasing global adoption as organisations seek to optimise cost and streamline access to cloud applications.

The technology enables organisations to build higher-performance WANs using lower-cost and commercially available Internet access, by partially or wholly replacing more expensive private WAN connection technologies, such as Multi-Protocol Label Switching (MPLS), or to introduce a second or third application hub into the traditional hub-and-spoke WAN topology.

SD-WAN technology connects enterprise network end points, including branch offices and data centres, and is considered an advancement in building adaptive networks to suit these needs, while lowering operating costs.

Due to this technology being extremely new, there are only a few original equipment manufacturers (OEM) in the market that offer practical SD-WAN solutions, either as a standalone product (deployed by the end-user via a reseller) or as a fully managed service by an integrator, who is also a channel partner of the OEM. It is therefore imperative that, as a customer, an organisation needs a very clear understanding of what it wants the SD-WAN solution to deliver.

Legacy MPLS was standards-driven and all service providers delivered the same basic service, with the differentiating factors being based on the capability of the service provider (i.e., services like reporting or capabilities like network footprint).

The main differentiator between MPLS and SD-WAN is how SD-WAN is configured. The challenge that prospective customers (service providers or enterprise end-users) face related to SD-WAN is that there is no ‘standard’ implementation across the industry. Different approaches are also adopted related to last-mile technologies that influence the optimal tuning of each circuit. The market does, however, expect SD-WAN to be a cheaper alternative to MPLS and one that offers more functionality.

One of the key benefits of deploying an SD-WAN solution is the reduction of operating costs. We typically see that a cost reduction of up to 40% is achieved, but this figure carries the mandatory ‘terms and conditions apply’ warning as the savings realised depend on a multitude of factors, least of which is the brand of the SD-WAN product.

Another key benefit is agility, in terms of rapid deployment. This is especially the case in the small office space within any industry and where the customer’s core applications are already web-friendly. It is not so much about the technology, but more related to system deployments and how they are adapted to leverage SDN capabilities.

Organisations also need to keep in mind that larger enterprise environments will find it more difficult to deploy SD-WAN due to the operational silos of IT/networking and security. It is crucial to blueprint security into the SD-WAN design as direct Internet access from the network periphery bypasses the traditional centralised security controls.

SD-WAN works well with smaller businesses that already have workloads in the cloud where benefits can quickly be realised. This is also where the different OEM products and tool-sets will position themselves as differentiators in the market to meet the needs of their customers.

It should also be mentioned that caution must be applied to the OEM messages around SD-WAN and customers should understand the context of these messages. They are very ‘use case’ specific. It is important to have a clear understanding of what the benefit is that the OEM provides.

Another issue to consider is how a specific OEM’s product will fit into your environment, while also understanding your own cloud roadmap.

Successful SD-WAN deployments typically stem from cases where customers knew where they were going and identified SD-WAN building blocks to take them there. The effort spent around analysing the use case and cost benefit was carefully evaluated – so, don’t be taken in by the hype.

Share this article:

Further reading: