If things work out the way proponents hope, software-defined WANs will make tying corporate locations together far more efficient, increase functionality and reduce costs.
SD-WANs are an implementation of software-defined networks. Today, network elements are purpose-built physical devices. If a company wants a firewall to protect an office, it calls a service provider or carrier who sends out a guy – it always was a guy – with a firewall in a truck. He deploys it into the network.
Think about that truck roll. First of all, it doesn't happen immediately. The order is fulfilled days or weeks after it is received. It's also costly: There is the hourly pay of the technician, the gasoline to get to and from the site and costs associated with the vehicle.
Until very recently, these negatives were accepted as unavoidable. Things are changing, however. Software has become so powerful and networking so fast that what a firewall does can be executed in the code. Hardware still is needed, but it is minimal and only called on to perform rudimentary tasks.
This has two big ramifications. The hardware tasks done in the field would be common to all equipment. This means that a generic box would be deployed at strategic points and told what to do as needs changed. Software telling that machine to stop being a firewall and start being a load balancer, for instance, would be downloaded.
In the world if SD-WANs, service providers can add and reduce capacity, reconfigure networks and perform other formerly onerous tasks by checking off a few drop down menus. The generic hardware is deployed once. This means that a good deal of the cost associated with the field technician and the vehicle is off the books. The lead time between the customer order and the change of service is largely eliminated.
Nowhere is the grand idea grander than in the world of corporate wide-area networks (WANs) that link headquarters, satellite offices, branch offices and other assets. They marry this idea to new approaches to how the overall WAN is configured. Today, WANs usually are linked via the Multiprotocol Label Switching (MPLS) protocol. It is a solid platform that supports service level agreements (SLAs) that experts say is mature and elegant. But it is an expensive approach.
The challenge is that WANs that depend solely on MPLS are overkill. Much of the data a company moves across its WAN can use broadband. Sending the final standings of the corporate software league over MPLS is wasteful, for instance. Older WAN architectures also use hub and spoke configurations: All data is sent from the edge to a central point – usually the data center – and back to the edge. This chews up bandwidth needlessly and plays havoc with latency-sensitive applications, such as video, that were not a factor when the WANS were originally architected.
SD-WANs are overlays that change the scenario in two important ways. The first is that the data center no longer is the center of the universe (or at least the corporate LAN). Local nodes are arranged in mesh configurations with other nodes, enabling data to be routed flexibly. The other change is that broadband – likely from cable companies, telcos or wireless service providers – serves alongside MPLS. Thus, sensitive video still may be assigned to MPLS, but the news that the Akron plant beat the Toledo corporate headquarters 4-3 in the final game is sent via broadband. It's fair to point out, however, that security costs can be higher in SD-WANs because each of the nodes must be more thoroughly protected.
The best advice for an organization investigating SD-WANs is to remember that it is a new and rapidly evolving sector. The first iteration of SD-WANs focuses on bandwidth provisioning. This is a great asset: Capacity additions for the holiday shopping season no longer have to be done during the fall. And an unexpected uptick in traffic, such as a shoe company with an unexpectedly hot item, can be accommodated in what essentially is real time.
The second version adds technical elements that enable the system to find the best path between locations based on the desired parameters and real time data such as network congestion. The next stage – referred to as SD-WAN-as-a-service – is to relocate software elements in the cloud. This will make SD-WANs more flexible and help enfranchise mobile users and cloud providers.
The SD-WAN era is young. Therefore, many of the vendors and service providers open for business today may not be around tomorrow. They may go out of business or be acquired by other vendors. SD-WANs have great potential but should be approached carefully.