Moving infrastructure from premises to the cloud can make sense for a lot of businesses. Few are going to look back on their lives, warmly recalling that time that they backed up their Exchange server or increased someone's mail quota. Microsoft and Google (among others) can both run your mail system for you for a reasonable monthly fee.

And Mail is just the start. While mail is perhaps the most natural cloud service (since it's been a cloud service before there was such a thing as "the cloud"), customer relationship management software (such as Salesforce.com or Microsoft Dynamics), communication and collaboration (such as SharePoint and Lync), office productivity (such as Google Apps, Zoho, and Office 365), and even entire desktops are all available as cloud services.

To use any of these services you will need a connection to the Internet. The office Internet connection is always important, of course. Even in the pre-cloud days, it was annoying to not have access to e-mail or the Web. But with cloud services, the burdens placed on the Internet connection become a whole lot more serious. An overtaxed Net connection becomes a dire impediment to productivity.

While on-premises systems can benefit from nice fast LAN connectivity, with even 10gigE becoming a fixture in the server room and gigabit common elsewhere, cloud services generally have to make do with much scarcer bandwidth resources. For small and medium businesses, Internet bandwidth tends to be measured in the megabits, typically dozens, but sometimes in the single digits—especially for branch offices, retail premises, and other small sites.

That's unfortunate, because a good case could be made that these are the sites that stand to gain most from cloud services, thanks to their lack of on-site IT staff. Even some of the less common services, such as virtual desktop infrastructure (VDI), can make sense in such environments: VDI means that the equipment on premises doesn't need to store any data and so isn't at such risk of theft.

Varying needs

Bandwidth requirements will of course depend on the service being used. Common services like e-mail tend to be fairly easy on the bandwidth. Some less common services, such as cloud-hosted virtualized desktops, by contrast, can place heavy per-user demands on an Internet connection, especially in deployments with high resolution desktops or multimedia.

Some tasks can be highly variable. Cloud storage services—whether straightforward file sharing such as Box and Dropbox or more complex document management like SharePoint—can end up using a little bit of bandwidth or a lot. Word documents and Excel spreadsheets are generally relatively tiny; photographs and videos can be huge. The occasional upload of a big file to cloud storage can be enough to clog up the Internet tubes, which on shared connections is a problem for everybody.

On top of bandwidth, there are also important latency considerations. Some applications, such as e-mail, are pretty latency insensitive. That's not to say that lower latency isn't better—it makes everything a little snappier—but desktop mail clients, and most Web-based applications, tend to be designed to be tolerant to a certain amount of latency.

Other applications aren't so robust. Latency is absolutely killer for voice over IP. Short delays of a few tens of milliseconds are enough to make calls sound strange. Hundreds of milliseconds can render them almost unlistenable, with 150 milliseconds generally regarded as the limit for tolerable voice calls.

VDI is similarly sensitive: snappy desktop experiences demand low latency connections to service providers. In many ways, the issues with VDI can be the most acute. Web apps don't generally place demands on the network once a page is loaded, so a lot of the time latency is masked. You don't notice the slow network when you're not actually using it. They also have clear, well-defined points at which you have to wait—the submission of a form or clicking of a link. VDI, however, places nearly constant demands on the network, and it can make you wait anywhere within an app. On slow links, even navigating with the mouse, clicking buttons and typing can be disrupted.

Moreover, if a single local or Web-based application is a bit slow, users can often switch to some other task temporarily. If all their software is delivered through VDI, however, there's no such escape route. A choppy virtual desktop will make every application they use unusable.

And of course, these issues can be intertwined: as we saw in the examination of latency, the large buffers on modern routers mean that bandwidth shortages (or rather, mismatches between local bandwidth and upstream Internet bandwidth) can in turn cause massive latency of many seconds. When latency is this high, even latency-tolerant applications can become thoroughly unpleasant to use.

Figuring out just how much bandwidth you need—or conversely, which services you can practically use given the bandwidth you already have—can be non-trivial.