Azure ExpressRoute

Ever since Microsoft announced the general availability of Azure ExpressRoute for Office 365 last September, our customers who use WAN Optimisation have been asking if and why they still need WAN Optimisation Technologies.

So why do I still need WAN Optimisation Technologies

When we speak with our customers (new and existing) about Office 365 and Express Route, I frequently get asked, “why do I need WAN optimisation if Express Route will give me lower latency and better connectivity to Office 365?”

I frequently find myself reminding people of the three main reasons why cloud applications are typically “slow”:

  • Insufficient bandwidth (and of course more applications competing for it)
  • TCP inefficiency – especially in the presence of packet loss and jitter
  • Inefficient applications (chatty applications that aren’t really written for cloud or WAN)…most older apps!

The issues above do not appear in isolation and if they’re not all addressed at the same time and in a uniformed way, then it’s likely that applications will continue to function poorly or cause a real drain on your limited bandwidth (Express Route or not).

Of course, by throwing enough cash into a big Internet Pipe(s), Express Route can certainly address the issue of insufficient bandwidth. Since Express Route also peers directly with Microsoft, it is “reasonable to assume” that, unlike a public Internet Exchange point (or MPLS – which of course has to break out to he Internet eventually), the chance of encountering packet loss due to congestion is mitigated…or at least reduced!

So WAN Optimisation IS still Needed then?

The biggest issue (after Bandwidth starvation) of poor application performance over the WAN or Cloud is that if “TCP and application inefficiencies” which still remain with Express Route. This is the core area where Riverbed SteelHead can help and the are that has made it the Gartner Magic Quadrant leader 8 years running. Riverbed SteelHead together with Microsoft have official support for Express Route and specifically for Exchange Online, SharePoint Online and OneDrive (and OneDrive for Business) workloads.

Since Riverbed SteelHead acts as a TCP proxy and is “application aware”, it can overcome and eliminate these TCP inefficiencies found in the WAN. SteelHead also understands the “language” which the application “speaks” and can overcome the application inefficiency within it. For example, the SteelHead appliance understands both the Outlook anywhere and MAPI-over-HTTP protocols that Exchange Online uses.

So how much faster Does SteelHead make Office 365?

This is of course a subjective question because like anything it depends on a number of things. What your bandwidth is, how many other cloud apps you have, how many people are accessing resources, where from and how big are the files or data you are looking to optimise…

One of the most common workloads is email, so in tests, moving an email containing a 13MB attachment from the Inbox to the Online Archive across a WAN with 10Mbps of bandwidth and low latency of only 60ms is a fairly common one. Microsoft still recommends running Outlook in “cached mode”. Cached mode is available when working with your Inbox but is not available with the Online Archive. Using Express Route alone, it took 71s.

Well…that’s a bandwidth issue right? – more bandwidth= faster transfer times? Let’s see – 13MB/71s = 1.5Mbps = only 15% of the 10Mbps – So not a bandwidth problem.

With SteelHead optimization, the same operation took only 7s providing a 10x speed increase. Of course, Riverbed can’t guarantee a 10x increase in every operation but the overall impact is significant to improving the end-user experience – and this is what it is all about. Slow Applications = Slow Business.

Sticking to email, let’s look at uploading of PST files or mailbox migrations to Office 365 (something every business has to do when migrating to Office 365).

Over this same 10Mb Express Route connection (un-contended with no other users), uploading 5 PST files with a total size of 1.3GB over Express Route took in tests 355s. With SteelHead Turned on, this took 136s (so less than half the time). The most interesting stat here is what SteelHead does to the amount of data being transferred across the WAN – in this example, traffic was reduced by 85% – from 1.3GB down to only 190MB

Remember – Application Performance = Business Performance

Rob Quickenden, Chief Strategy Officer at Cisilion