Which Way to the Cloud-Ready WAN?

The movement to cloud-based services is well underway—over 50% of CRM applications are already SaaS-based. Yet most corporate WANs are still built for the pre-cloud world, focusing mainly on efficient data transmission between branches, headquarters, and data centers. Essentially, the “historical” corporate WAN was optimized for transferring information between physical locations owned or rented by the enterprise.

But as we all know, the world has changed. So when examining how the WAN architecture should change along with it, we find inherent trade-offs between centralizing and distributing functionality.

With the central approach, all Internet-destined traffic is backhauled through a firewall at a central location.   This “hub and spoke” design is straightforward to secure, but the inevitable backhauling is sub-optimal in an environment where cloud services are important (note a branch in Los Angeles accessing a service in Seattle through a data center in New York).

Centralized “Hub and Spoke” Design Results in “Tromboning” of Traffic Accessing SaaS Services

In many enterprises today, cloud applications are generating the majority of traffic, driven by the continued adoption of Software- and Infrastructure-as-a-Service (SaaS and IaaS). In response, enterprises are motivated to consider a fully distributed or direct-to-net architecture.

The left side of the diagram below illustrates the direct-to-net approach and the associated complexity: going directly to the Internet means installing a firewall at every branch. So do we have to choose between the direction of “fully centralized” (backhauled) or “fully distributed” (direct-to-net)?

How “Direct to Internet” (Left) Sometimes Gives Way to a “Regional Hub” Architecture (Right)  [click for full-size image]
How “Direct to Internet” (Left) Sometimes Gives Way to a “Regional Hub” Architecture (Right) [click for full-size image]

No. As Gartner’s Andrew Lerner points out, “If you go with the traditional WAN architecture, the cloud apps will suffer. If you go all Internet VPN architecture, the corporate apps suffer.” In response, many enterprises have turned to a regional hub approach (illustrated on the right side of the above diagram).

However, because the network relies exclusively on IP routing, the hubs may indiscriminately direct traffic to either service (SaaS-1 and SaaS-2 in our case) regardless of the likely latency. Despite these potential inefficiencies, the regional hub approach often strikes a good balance and solves many of the problems in creating a cloud-ready WAN.

Moreover, a security-as-a-service solution (such as Zscaler, a Silver Peak partner) can provide similar benefits to a regional hub architecture, as secure virtual gateways can separate regional/branch business traffic from Internet traffic, redirecting each traffic type accordingly.

Another advantage of using regional hubs comes into view when you consider other web services, such as “home from work” mail services or social media (depicted by the “Web Services” above). For services such as these, you don’t care about optimizing traffic, and you certainly don’t want to have to log all access to it.

Finally, an SD-WAN architecture moves us closer to being fully cloud-ready by taking any existing corporate WAN (which may be based on MPLS) and optimizing it with available broadband links. For example, the Silver Peak Unity SD-WAN architecture improves on the regional hub approach by determining the optimal egress hub for each cloud service component, and by determining the best path from each branch to each service hub.

Along with business intent overlays, Silver Peak brings together the capabilities of Zero Touch Provisioning, Dynamic Path Control, and dynamically applied latency mitigation and data reduction to give customers the flexibility to access cloud services as efficiently as in-house applications.  The right SD-WAN feature set, perhaps combined with a regional hub architecture, leads to a cloud-ready WAN.