Official Support for Optimizing Office 365 via Azure ExpressRoute
Last September, Microsoft announced the general availabilty of Azure ExpressRoute (ER) for Office 365. Since then, customers have been asking us whether we would support this architecture. I'm excited to announce our official support for this architecture using the Exchange Provider model (EXP) and specifically for Exchange Online and SharePoint Online/OneDrive workloads. When I talk to our customers about ER, a recurring queston I hear is: "Why do I need WAN optimizaton if ER promises lower latency and better connectivity?" To answer this question, let's revisit the three main reasons why applications perform suboptimally when accessed across the WAN:
- Insufficient bandwidth
- TCP inefficiency especially in the presence of packet loss; and
- Application inefficiency
Remember, the above issues do not appear in isolation and if they're not all addressed at the same time, then it's likely an application would continue to function suboptimally.Try SteelHead for free
By purchasing a large enough pipe, ER can certainly address the issue of insufficient bandwidth. ER also peers directly with Microsoft hence it's reasonable to assume that, unlike a public Internet exchange point, the chance of encountering packet loss due to congestion is mitigated.
However, the issues of TCP and application inefficiencies remain and this is something that ER does not address and where SteelHead can help. Riverbed SteelHead helps because it acts as a TCP proxy and can overcome the TCP inefficiencies found in the WAN. SteelHead also understands the language the application "speaks" and can overcome the application inefficiency. For example, the SteelHead appliance understands both the Outlook anywhere and MAPI-over-HTTP protocols that Exchange Online uses.
Just how much faster is SteelHead optimization running on ER vs ER alone? One workflow we tested was moving an email containing a 13MB attachment from the Inbox to the Online Archive across a WAN with 10Mbps of bandwidth and 60ms of latency. Most people are probably aware that Microsoft recommends running Outlook with cache mode. Cache mode is available when working with Inbox but is not availabe with Online Archive. Using ER alone, it took 71s. Now, you might be thinking to yourself: it's a bandwidth issue. Let's calculate this: 13MB/71s = 1.5Mbps = 15% of the 10Mbps and therefore it can't be a bandwidth problem. If this was sending an email in Outlook using cache mode, the user would be able to continue working in Outlook. However, because Online Archive doesn't use cache mode, this particular operation caused Outlook to lock up for the entire 71s.
With SteelHead optimization, the same operation took 7s providing a 10x increase. Of course, we're not promising a ten-fold increase in every operation but the overall impact is significant to the end-user experience.
This announcement marks the completion of phase one of the project that we're doing with ER and we look forward to helping our customers migrate to Office 365 in the coming months. While I'm not in a position to reveal the other ER related initiatives that we're working on right now, I can promise you that you will not be disappointed when we make the announcements, so stay tuned for more updates.