This article was originally published on Networkworld.com on June 4, 2018 by Mark Casey, CEO of Apcela.
How to get more from your SD-WAN deployment with a cloud-ready WAN.
In the eternal words of Yogi Berra, “If you don’t know where you are going, you’ll end up someplace else.” So how does this sage advice apply to the new world of application performance and hybrid IT?
As the pace of application migration to the cloud continues to accelerate, enterprise networking teams have turned to hybrid and SD-WANs as practical solutions to open up more localized internet access and direct routing to the cloud. So the theory goes that by deploying broadband and internet connections at the edge of the network, users can bypass the MPLS bottlenecks and avoid transiting the centralized data center internet egress points.
So with the proliferation of hybrid and SD-WAN deployments, which according to most analysts is well past the tipping point and going mainstream, why is it that enterprise IT teams are still struggling with cloud application performance? User frustration with the performance of applications like Office 365, Salesforce, Workday, ServiceNow, and others is only growing, rather than waning.
Why we need an app map
To close the performance gap, we need to create a map that can show us both where we’re going and how best to get there.
Often, as our applications move out of the data center we don’t know exactly where they are anymore, it’s no longer our problem. But it is of course, because not having this information leaves us to rely on the public internet for access. That might be fine, except that the public internet is saturated with consumer traffic, and particularly video streaming from apps like Netflix, YouTube, and Facebook. According to Cisco, bandwidth consumption from online video will triple to make up 82 percent of all internet traffic by 2021. We’re competing with these consumer apps for delivery of our business and mission-critical applications.
As such, it’s now imperative that we take the time to figure out exactly where in the cloud our applications reside and how best to get to them, or at least how to avoid the consumer app congestion.
So, how do you map your apps and users to the cloud?
Let’s take a deeper look at how this applies. Suppose we’re migrating from a suite of on-premises based Microsoft applications to the cloud. Those typically include Office, Exchange, Skype for Business — conferencing and/or VoIP, Sharepoint, OneDrive, and a few others.
As we migrate these apps off premises to the cloud, we may initially find ourselves with a simple peering equation. Microsoft offers over 100 peering locations globally, and there is surely one very close to our current data center internet egress point(s).
So, let’s say that our primary data center is in the Chicagoland area, we have a branch office in New York, and the Microsoft application user they are accessing resides in Microsoft’s US East region.
As we migrate to the cloud, our users in New York transit the corporate network to the data center in Chicago where they egress through our security environment to the internet. If we’ve set up our peering correctly, we’ll hop on the Microsoft network in Chicago and ride it back to US East. Not bad, but wouldn’t it be more efficient to just jump on the public internet locally in New York, peer to Microsoft there, and ride a more direct route to US East? That, of course, is why we’re deploying local internet connections.
But let’s say we’re actually headed for an application instance that is in Microsoft’s US North Central region. If it’s in North Central, riding the corporate network to the Chicago data center and egressing to Microsoft’s network there is actually the better solution, because the performance of our corporate network is likely going to be better than Microsoft’s peering network. So forcing the Microsoft traffic out at the local branch may not be the right answer, and the right answer might be different for each Microsoft app.
That’s just for Microsoft. Multiply that by the number of cloud applications our users need performant access to, and the equation gets complicated quickly. Microsoft also has one of the best global peering networks. We will not be so lucky with most other SaaS application platforms, unless the platform is hosted on Azure, AWS, or Google. But then we’ll want to know which one and where for each of those as well.
Why SD-WAN is not a silver bullet
So why do we think SD-WAN is not the answer to all of our cloud application performance challenges?
Well it seems that IT teams, and particularly those within large, complex global enterprises have become particularly adept at technology deployments but have traditionally relied on existing carriers for WAN transport architecture. When all of the applications resided in centralized data centers, the existing MPLS networks provided by the carriers served us well, with strong performance, if not specific SLAs, around availability, latency, jitter, and packet loss.
As the public internet has become an increasingly critical component of the enterprise WAN and our application performance, this legacy model and architecture starts to break down.
As it is likely that we still have some significant percentage of our applications in the enterprise data center, we still need our single or dual provider MPLS networks, which may also include a federation of regional MPLS networks. On top of this, to address the cloud side of the WAN and our increasing bandwidth requirements, we’ve added a fragmented base of dozens of new broadband and internet services provider connections.
Because we’re good at technology deployments, we instinctively turn to new technologies like SD-WAN to tame this growing beast. SD-WAN alone though, can’t deliver us the application performance we’re hoping for, because SD-WAN is just a technology, it’s not the actual network. We need to deploy optimized network routes and internet peering that deliver the best latency, jitter, and packet loss between our users and their applications.
Building the foundation for a cloud-ready SD-WAN
So, in summary, we first need to understand where our applications reside. Then we need to measure and map the network flows between our users and all of the applications they’re using, both in the data center and in the cloud. The good news is that many enterprise networking teams already have the network and flow monitoring tools needed to do this most of this mapping.
Armed with this intelligence, we can begin to evolve our WAN transport architecture to optimize routes and peering points to deliver application performance in this new normal that is hybrid IT.
With an optimized transport architecture in place, abstracting the public internet with performance managed routes wherever practical and economical, we will have solid foundation for cloud application performance. The application-aware routing capabilities of SD-WAN then become both critical, and incredibly powerful as we find ourselves on the path to accelerating hybrid IT.
