Another cloud disadvantage is…
Performance. Cloud implementations have one strike against them from the get-go; with a few exceptions, they can’t possibly feel as crisp as their all-desktop equivalents because of network latency and bandwidth issues. Accessing your Exchange account through a browser provides an experience that looks remarkably like Outlook, but the performance is dramatically different. Same with the web versions of Word and Excel.
That’s if everything is going right if you’re using a cable modem for Internet access, and your neighbors are all watching streamed movies and TV shows, things will get downright pokey. But performance impairments are not limited to the network connections. Your cloud provider is economically motivated to get as many customers as he can on as few machines as possible. This saves him money, and it could be argued that it is the environmentally responsible thing to do. Response time versus processor load graphs usually have a hockey stick quality to them: with light processor load, adding users only modestly affects response time, but after adding more and more users, things reach a point where increasing the processor load by one or two users can cause dramatic upward shifts in response time. This point is hard to predict, because it depends not only on the number of users, but on what they’re doing. If the cloud provider is trying to give the users the best possible experience, he will stay well away from the place where the curve starts to bend upward. However, that means that most of the time, he’s leaving money on the table. It’s awfully tempting to pile on the users. I’ve certainly seen that happen with web hosting.
The performance hit associated with cloud computing can be ameliorated by the right partitioning of function. The Outlook/Exchange interface is worth looking at here. Once the messages are downloaded, the responsiveness of the user interface is strictly under the control of Outlook. Messy downloading and synchronization takes place in the background, with unobtrusive but easily seen progress indicators at the bottom of the window. Indeed, Outlook runs just fine completely disconnected from the Exchange server, and re-synchronizing when Internet access is again available. Synching a new Outlook client to an Exchange server can take hours over the web versus minutes on an LAN, but all that activity can take place in the background.
Here’s one exception: if you’re massaging data that is already located on a server somewhere in the cloud, you may be better off with most of your application running there. For example, say you use Dreamweaver to maintain your website. To make the case even more convincing, that you do most of your work in the HTML window. As things are, you have to wait for files to download before you can edit them. If the guts of your HTML editor ran on the same server that’s hosting your website, there wouldn’t be any noticeable download delay; the only delay you’d see is in painting the code into your editing window. Come to think of it, I could do that now with telnet and Emacs or vi, but that doesn’t seem very modern.
Leave a Reply