I’m having lots of conversations with people about deploying services in Azure, normally running in virtual machines. Most of the time, people are thinking about moving legacy services, such as line-of-business (LOB) apps with thick clients or things like file servers into Azure. But these people usually forget something important: the laws of physics and their impact on user experience when accessing remote services.
Almost everyone focuses on bandwidth when they talk about deploying services in Azure. Yes, bandwidth is very important, but few ever think about the impact of latency on the experience of using those services.
Imagine this scenario: A company moves file services from their LAN to a virtual machine running in Azure. They have a nice 50 Mbps connection to Azure; that should work pretty well. However, users complain that accessing file shares is slow. The response: ADD MORE BANDWIDTH!
The company has made it possible for more users to have the same rubbish experience. A file servers is a legacy application; it is very chatty and assumes that the client and server are connected by a low-latency network (a LAN). On a local area network (LAN), you have near zero latency — PING normally measures it under one millisecond in a healthy network. That means that every request, response and acknowledgement travels between the client and server in under one millisecond. Even a small data transfer, such as browsing a shared folder in File Explorer is made up of lots of these communications. The act of browsing one of these folders appears near instant when the file server is local. But what happens when you put the file server at the other end of a remote link with a 50 millisecond or slower long distance link? Expect users to start calling the help desk — no amount of bandwidth will solve the issue.
To solve the issue of latency, there’s no need to use technologies, such as Remote Desktop Services, Windows BranchCache or network appliances, such as Riverbed. There’s also no need to use more appropriate technologies, such as document libraries in Office 365. Instead, one simply needs to bend the laws of physics by warping the universe. Yes folks, I am proud to announce a new solution called Wormhole Area Networking (WHAN), trademark Aidan Finn, 2015. This technology, illustrated below, is a revolutionary solution for solving the issues of latency. One simply uses pure will and determination to bend the universe so that packets can flow a short distance between user devices and virtual machines in any remote location, such as Microsoft Azure. How low can latency get? If you’re determined enough and concentrate really hard, then you can create a wormhole directly between the NIC of your device and the NIC of the Azure host, achieving near Remote Direct Memory Access (RDMA) levels of performance!
I am making this solution freely available to the public in the hope that Microsoft will integrate it into Azure as they did with other community solutions, such as Hadoop and Docker. With this technology in place, anyone can move any application into a remote cloud without needing to consider how latency will impact user interaction with legacy services that are moved to the cloud.
Further innovations are in the works:
WHAN isn’t for everyone — not everyone has the will and determination to make it work. Those unlucky few can consider technology solutions that have been around since the 1990s for solving long distance network connections issues.
Caution: Using WHAN while drinking coffee may lead to out-of-order packet flow and alcohol might cause packet loss.
In case you are wondering, my tongue is placed firmly in my cheek with this article; it was written out of pure frustration. The actual solutions for moving legacy services and apps are:
But I am claiming all rights to WHAN before Apple or some troll tries to take them from me!