Today’s Enterprise WAN Isn’t What It Used To Be
Summary
Today’s enterprise WAN isn’t what it used to be. These days, a conversation about the WAN is a conversation about cloud connectivity. SD-WAN and the latest network overlays are less about big iron and branch-to-branch connectivity, and more about getting you access to your resources in the cloud. Read Phil’s thoughts about what brought us here.
For most enterprise NetOps teams, a discussion about the WAN is a discussion about the cloud. Whether it’s as simple as ensuring solid connectivity with a SaaS provider or designing a robust, secure, hybrid, and multi-cloud architecture, the enterprise wide area network is all about connecting us to our resources, wherever they are.
How it used to be
When I started my career in networking, servers were down the hall or in the campus data center. The WAN was how we got access to some websites and sent emails. Most resources were local, accessed remotely over some sort of leased line, or at worst, over a site-to-site back to the organization’s private data center.
QoS on the WAN wasn’t a thing outside an SLA you might have on a private circuit, and running anything mission-critical over an ISP’s network was sketchy at best, especially for sensitive traffic like voice. We just didn’t do it because the quality was low and generally unreliable.
What changed
Over the last 15 years, though, the quality of the public internet has improved significantly. Just think about the audio quality of your last Zoom call. Sure, maybe it wasn’t absolutely perfect, but you have to admit that it was probably just fine. Yes, there’s something to say about how applications are written, but on the public internet side, we’ve seen a decrease in latency, cost, and a massive increase in available bandwidth.
This coincided with the advent of the public cloud like AWS, Azure, GCP, etc. Because the public internet has generally become better quality and more reliable, moving resources, even the mission-critical, to these public cloud providers became feasible and desirable once you factor in the other benefits the cloud offers you, like agility, speed, and (virtually) unlimited scalability.
And if you think about it, many, if not most, enterprise organizations today are hybrid, multi-cloud, or both, often without realizing it. Even a small business with 100 employees in a single region uses SaaS providers like Google, Microsoft, Salesforce, Quickbooks, and many other cloud-based applications. Even a simple thing like Active Directory in the cloud means almost nothing needs to live locally anymore unless you have a particular need to do so.
The result of moving resources to the cloud and using SaaS is that the very concept of branch office routing has also changed. Why do we need to create site-to-site VPNs or some sort of modern SD-WAN topology connecting all our branches when almost all traffic goes to the public internet and the cloud?
Yes, of course, I’m oversimplifying here. Some organizations have security requirements to backhaul their traffic to a single security stack, and some organizations have found it more cost-effective to bring specific resources back in-house. But by and large, the vast majority of traffic is going up and out, not branch-to-branch.
What is today’s enterprise WAN?
So what does this mean for today’s enterprise network engineer? What can we say is the enterprise WAN of today?
Personally, I don’t think it’s any of those anymore, though ten years ago, it’s precisely what I would have said. I haven’t even mentioned CASBs, NaaS, containerized network services, and NFV, so you can imagine how the concerns of today’s network engineer are so vastly different from an engineer from yesteryear trying to figure out NHRP and BFD settings.
Today’s wide area network is predominantly how we connect to the cloud for small, medium-sized, and even large enterprise networks. Of course, we still have to think about new security issues, new visibility problems, new skills, and figure out who’s responsible for what.
So where are we today? What is the enterprise WAN?
We still need to connect our infrastructure to the public internet, so the enterprise WAN is still about routers, circuit IDs, and perimeter firewalls. But today, those routers are likely a centrally managed SD-WAN, and those perimeter firewalls could be a CASB or other cloud-based firewall service.
Since the need to backhaul traffic has gone way down, and the need for branch-to-branch connectivity is all but irrelevant for most organizations, the enterprise WAN is more like a collection of standalone networks under a single administrative domain. Today, engineers are dealing with an SD-WAN controller, a centralized CASB interface, and cloud-based network services like DNS and user authentication.
This also means that today’s enterprise WAN poses new challenges for a network engineer.
For example, cloud visibility, container network visibility, and public internet visibility are much more important today than they once were, but that type of visibility isn’t easy. It requires new tools, skills, and an understanding of how application traffic travels over the internet.
Also, service chaining network functions could lead to vendor lock-in, which may not necessarily be so bad, but it’s a potential problem when relying on so many third parties for application delivery. It’s not a deal-breaker, but I have seen the headaches with some customers when switching from one CASB to another.
I know there are always exceptions. There will always be those few organizations that require, for whatever reasons, to completely own and manage their own traditional WAN with legacy devices and topologies. But those are the exception. Today’s WAN is all about cloud connectivity, which means changing how we approach routing, perimeter security, and network operations.
The new reality is the WAN isn’t what it used to be.
