blockquote_thumb1[1]… where response time and speed are concerned, many businesses automatically assume Google.com- and Amazon.com-levels of performance from services such as Google App Engine and Amazon EC2, but this can be a mistake.

-- ESJ, “Q&A: Managing Performance of Cloud-Based Applications and Services

A big mistake, indeed. While the underlying systems may be optimized and faster than fast, that doesn’t mean that applications won’t suffer poor performance. There are many other factors that determine how an application will perform, and most of them are variable. They can change from day to day, hour to hour, and from user to user. It certainly won’t hurt to optimize the network and, for providers at least, it’s about the only thing they can do to help customers whose applications may be suffering from performance problems.

Network optimization is a very different game from application and application delivery optimization. The former focuses on well, the network and doesn’t take into consideration anything about the application like protocols and connections and repetitive data delivery. The ability to accelerate an application (because that’s really what we’re talking about) is not something that can be achieved solely by optimizing the network. Optimizing the network does not impact the application’s ability to process requests and return responses, nor does it improve the capacity of the application, nor does it reduce the chattiness of an application protocol. It doesn’t do anything for the application because it’s is, appropriately, focused on the network.

Application performance issues can be caused by poorly performing networks, yes. But a provider only has access over one leg of that network – the one they control. Poor performance caused by networks outside the organizational boundary of control cannot be addressed by localized network optimization.