Feb 13, 2017 Direct to Internet – Great, Except When It Isn’t
One of the great challenges of the present moment in IT and specifically for the WAN is resolving the disconnect between application and service architecture on the one hand, and the architecture of the WAN on the other. In a nutshell: the continuing shift of work to the cloud makes poor use of the WAN, and the dominant WAN architecture of backhauling all Internet traffic to a major data center does cloud-bound traffic no favors.
One of the major appeals of SD-WAN is that it promises to provide new leverage on this problem. First off, it embraces Internet connectivity at the branch as a primary communications channel. Second, SD-WAN allows splitting the Internet link between internal traffic traveling by VPN to some other part of the WAN and external traffic heading directly to an Internet destination from that branch. Thirdly, it layers intelligence into the mix: under direction of a centralized policy engine, an SD-WAN solution can decide which web- or cloud-bound traffic to let out directly and which to continue to send along internal channels to be handled elsewhere.
Many discussion of SD-WAN fail to fully appreciate the two facets of this third point: that direct-to-Internet can be highly selective, and that backhaul to a data center is not the only option for what to do with cloud traffic not headed out directly.
Organizations should be selective about what goes out and is allowed in directly, balancing performance for end users and efficiency in WAN use against security concerns. For those confident of their solution’s firewall functionality, most plan to make some use of direct-to-Internet. Commonly, they plan to send traffic to strategic cloud service providers (CSPs)–usually their key SaaS platforms–direct from branch to CSP, unless they have some kind of direct cloud connect from their data center to the CSP (such as an ExpressRoute to Office 365). Where they won’t send it direct, they usually have some specific security concern they are addressing through use of a security appliance in their data centers: data leak prevention, for example.
However, data centers are not the only way to approach solving this problem of layered security. Another is to use Internet security hub sites to provide those additional layers of security, more numerous and more widely distributed than data centers but far smaller in scale. They are often regionalized, so that an organization has (for example) a hub for the northeastern US, another for the midwest, another for the west coast, each equipped with the needed gear. Branch SD-WAN appliances can then selectively send all or only the relevant deeper-security application traffic through the nearest hub on its way out to the Internet, rather than through a data center proper. This reduces latency for the traffic (by routing it closer) and thereby having less of an impact on performance. Spreading the load can also reduce the load on data center WAN and Internet links, of course. More importantly, it can allow IT to deploy smaller appliances in each hub location as well as in data centers–perhaps bringing load down enough to make virtual appliances a comfortable option, further promoting flexibility and branch-stack consolidation even in the hubs.
So, although SD-WAN empowers direct-to-Internet connectivity from the branch, it’s not always the right option, or the only option for avoiding the data center backhaul. We discuss this, and more, in our report here: http://viptela.com/sd-wan/analyst-research/improve-enterprise-network-sdwan/ and in Nemertes’ session at the recent FutureWAN Virtual Summit (replays here: http://viptela.com/futurewan-sd-wan-virtual-summit/).