The Business Case for SDN: Part 2
Deciding how to adopt SDN can be daunting. Here’s how to get started.
SD-WAN is a painless way to get started with SDN and provide real business benefits in the process. SD-WAN products are essentially really smart WAN optimizers and do not need significant effort to provide benefits.
An SD-WAN system is installed at each remote site and at the home site, using multiple links between themselves. The link can be MPLS, broadband internet, or even wireless LTE. Multiple links are used to increase resilience and to segregate traffic. The latency, jitter, and packets loss of each link is measured on a continuous basis. Policies are used to determine the traffic type that should use each link, based on the link characteristics. I like to think of it as a form of automatic QoS where the SD-WAN controller can adaptively route time-sensitive traffic over the links that are best suited to it, based on the link characteristics. Bulk traffic is routed over other links, minimizing its impact on time-sensitive traffic.
SD-WAN products use policy-based configurations, which is the direction that networking products are going. By using SD-WAN, the network staff can become accustomed to policy-based network configuration, using APIs for configuration, and new methods of monitoring and management.
Multiple vendors now make SD-WAN products, so you have choices in products. Check specific product features to make sure they match the business requirements.
The Business Case
For SDN to make sense to a business, there must be a tie-in to the business operation. Does it save money? Does using SDN help make money, perhaps by increasing productivity? Does it provide a competitive advantage? SD-WAN provides benefits in all of these categories, without requiring an extensive deployment effort and a long implementation process.
The easiest way to save money is to use a combination of lower cost broad-band internet circuits. Using more than one broad-band internet circuit provides greater resilience, especially if the last mile circuits are diversely routed. Fewer expensive MPLS circuits are then needed, which can result in significant cost savings.
Efficiency can be increased by using voice and video to conduct business meetings between an organization’s sites. Traffic from remote branches goes over the internet links to reach cloud providers like Salesforce, avoiding any impact on traffic between the branch and corporate headquarters. This reduces latency in both cloud and headquarters applications.
Gaining competitive advantage is more challenging. Saving money and increasing efficiency are factors that increase competitive advantage, but more indirectly than directly. Adaptability to changing business environments and being able to roll out applications faster come to mind as possible advantages of SD-WAN (and eventually SDN).
SDN uses policy to control connectivity. SD-WAN uses policy to control traffic flows over each type of circuit. The SD-WAN controllers measure connectivity characteristics between themselves as packets flow, allowing the controller to direct traffic over the path that best matches the requirements of that traffic. For example, voice calls get routed over the links with the lowest latency, jitter, and packet loss. An MPLS link might be the best choice for voice. Bulk data, like email or document transfer, that needs bandwidth more than fast transfer times is routed over high-bandwidth links. A broad-band internet path would typically be the best choice for this type of traffic. Critical, interactive business applications would likely choose the MPLS links as well, but with a lower priority than voice traffic, so as to not cause increased jitter for voice.
Business Policy drives these link selection algorithms. Vendor definitions for default policies are frequently good, but may benefit from tuning to improve path selection for business-critical traffic.
Become accustomed to thinking about policy-based configuration instead of detailed device configuration. It is quite a different thought process and is liberating after working with it a while. You no longer have to translate high-level policy into detailed device configuration statements. The policy-based configuration system handles the details and allows you to work with the network with a higher-level business perspective.
Network automation is a big factor in SDN (and SD-WAN). Automation tools like Ansible, Puppet, Chef, and Salt are being adopted by many organizations. In a recent network automation class, we learned that configuring and verifying complex BGP configurations can be reduced to just a few parameters. In another example, an organization built a network automation system to configure a complete data enter pod from just a few parameters. One of the compelling benefits of these systems is their repeatability. Need to swap out hardware? The system can configure the new hardware very quickly. Need to add a new data center pod? Just feed the new parameters to the network automation system and the new pod is properly configured.
It can be daunting to try to adopt all of the functionality of a complex SDN solution. Getting started with easily-implemented technology is a better approach because it lets the organization start to learn about the technology while gaining business benefits. It is a journey which is simplified by taking small steps like SD-WAN, becoming familiar with the new technologies and how they function. Part of the change is cultural—switching from per-box configurations to network policy configurations. The sooner you start, the sooner you can benefit.