Your definition of SD-WAN may depend on when you joined the conversation. For some, SD-WAN is about hybrid WAN using diverse uplinks intelligently based on application requirements. For others, it’s about securely connecting sites over the WAN. And for others still, it’s about introducing software-defined control in a bid to become more efficient.
Whatever the starting point, this much is clear: SD-WAN is an operational transformation in the making for enterprises of all shapes and sizes.
The thing about operational changes
Indeed, some of SD-WAN’s value can be unlocked by merely deploying an SD-WAN device at the edge. With a secure router in tow, enterprises can unlock secure connectivity over the WAN and execute workflows from a cloud-managed controller. Operators can use that same software-defined model to gain visibility over a set of distributed devices. In many ways, the barrier to SD-WAN is fairly low, requiring only the will to move beyond current practices.
But the thing about operational changes is that they occur not only in the devices, but also the people.
Moving to controller-based management means elevating operations above the current device-by-device, command-by-command slog that has typified enterprise networking for decades. Operationally, this will ultimately prove easier. But when a workforce self-identifies by their certification numbers, such changes can be imposing.
Additionally, SD-WAN represents not only a change in the point of interaction (the controller over the CLI) but also a change in the altitude of engagement. Using declarative, intent-based models, operators are meant to specify requirements in abstract terms rather than behavior in explicit device primitives. Of course, to operate at the application level means networking teams cannot merely coexist with their application brethren. There must be a degree of collaboration that is frequently absent in the current siloed model of legacy IT operations.
Oh, what a tangled web we weave
Of course, these operational changes, if confined to a single set of devices at the WAN edge, are straightforward. But if software-defined principles are transformative, why would they stop at the edge?
It seems obvious that the SD-WAN movement will be but a waypoint on the path to a broader enterprise play. The architectural constructs and networking practices that are currently being applied to the WAN will extend over the wired LAN as well. And from there, they should logically continue down to the access layer, which is largely a wireless play.
When this happens, the practice of networking becomes more complex. The interdependencies between different systems across different parts of the network are not always known, and even when they are, the tools required to manage them have largely not existed. When networking teams purchase and deploy in silos, the suppliers tend to follow suit.
For example, in an actual SD-WAN deployment, an enterprise was making changes to the branch gateway that were to be pushed out to thousands of sites. Among the changes was one hidden in the MTU size that resulted in an MTU mismatch over the WAN. Such mismatches can lead to intermittent connectivity issues between the source and destination hosts. Merely checking for connectivity in the absence of actual traffic doesn’t necessarily guarantee success. If the network elements are treated in isolation, this change goes live the next day.
In this instance, the enterprise had extended its management domain from the WAN into the wireless LAN. By monitoring wireless experience, they identified intermittent issues down to the endpoint. This flagged that there was a problem, which was subsequently resolved in the SD-WAN gateway.
The key here is that operations is not a siloed function. If end-user experience is the new uptime, then networking teams must expand their purview beyond basic connectivity checks.
Diversity of infrastructure
One of the other driving forces behind SD-WAN is leveraging diverse underlying transport. An early premise behind hybrid WAN was the idea that not all applications require the same treatment. Enterprises should be able to make intelligent decisions about which uplinks are used. In this case, SD-WAN endeavors to make use of a diverse set of underlying transport options.
This is, of course, only possible if SD-WAN is implemented as a bridge from traditional to modern. When technology is treated as a greenfield adjunct to existing deployments, it can be difficult to marry the past to the future. As enterprises grapple with their SD-WAN plans, striking a balance between leveraging and retiring existing infrastructure will be important. When budgets and timelines don’t allow for a clean start, finding solutions that provide a path forward without stranding assets can be a cost-effective way of evolving.
The key in these bridging scenarios is unifying operations over diverging infrastructure. Indeed, one of the transformative aspects of SD-WAN is that abstracted control ought to create separation between management and devices.
Preparing for the future
Ultimately, the challenge in evolving to SD-WAN will not be in the deployment of gateway devices, but rather in exploiting the operational tenets beyond just the SD-WAN devices themselves. If enterprises believe this is a one-and-done purchase opportunity, there might be very little to consider. But for those that see the software-defined movement as a precursor to what is next, it makes sense to think through how the rest of the enterprise will be ushered into this era.
Specifically, how will the WAN and LAN come together? Will the network evolve as a single solution or as a collection of multivendor components stitched together through operational abstraction? How will workflows be treated? And how can control models take advantage of already emerging advances in areas like artificial intelligence?
While enterprise attitudes towards the future will undoubtedly vary, one thing seems clear; we are just getting started.