|
A cache by any other name is still a cache.
Whether they're referred to as Wide Area File Systems (WAFS), Web caches, or Web application accelerators, the fact of the matter is that caches take a myopic view to an important enterprise challenge.
Caching vendors claim that they solve these problems in one, easy-to-use device. They claim that their devices enable enterprise application acceleration, branch office IT consolidation, and bandwidth savings as well.
Caching, in fact, is a poorly architected, partial solution to enterprise application acceleration that may introduce more problems than benefits into a network. Caching devices, as we will explore in detail, seemingly improve throughput by short-circuiting the communication processes of applications and serving content locally. But this approach is limited in its efficacy, error-prone, and hard to manage.
This paper illuminates the 5 most dangerous shortcomings in the caching approach to enterprise application acceleration:
- Lack of breadth for application support
- Inability to handle common changes to information
- Data integrity weakness
- Inability to support disaster recovery
- Failure to really consolidate servers
Finally, this paper will present the Riverbed Steelhead appliance as an alternative to caches. By first understanding the shortcomings of caching, it will be easy to see why the Steelhead appliance is a more intelligent approach to meeting the application acceleration challenge. By the end of this paper, it will be easy to see how Steelhead appliances encompass the limited benefits of caching, but also give an enterprise much more acceleration power, breadth, flexibility, and manageability.
Read on to understand the ugly truths behind caching products and the troubles they can bring to your network. If you'd like to hear the real story behind caching, watch caching vendors squirm as they have to admit to these 5 deal-breaking limitations:
Ugly Truth #1: "You're likely to need multiple caches in each of your offices."
Caches are built by implementing a local server that supports a particular protocol. Because of this, a cache's functionality is limited to the protocol that the server supports. Caches then try to store local copies of data, and wherever possible, serve a client request from its local copy as opposed to requesting information across the WAN.
Even caching products that claim to support more than one application often consist of multiple servers implemented on the same machine. Often times, the servers need to be configured and managed separately, with their own set of constraints and management tools. Adding a new protocol to the cache involves the development of a new server for that protocol, including engineering the necessary coordination of data and actions between the local server and the origin server. Not only can this dramatically reduce the performance of the "multi-protocol" cache, but it will most likely make the cacheeven harder to manage and configure.
Ugly Truth #2: "If users make changes to files, caches are not very useful."
Caches often support pre-positioning operations that allow content to be moved into the cache in advance of any requests. Unfortunately, a cache's approach to pre-positioning is not very effective either. Again, this is due to the fact that caches fail to optimize transfers when file names change or a small section of the data changes. These two scenarios explain the impacts of pre-positioning with caches:
Best Case Scenario
Content is pre-positioned out to the edge, but soon afterwards the content on the origin server changes slightly. On receiving a client's request for the file, the cache recognizesthat the origin file has changed, and has to request the file over the WAN again.
Result of having a cache: No benefit
Worst Case Scenario
Content is pre-positioned out to the edge, but soon afterwards the content on the origin server changes slightly. On receiving a client's request for the file, the cachedoes not recognize that the origin file has changed, and serves old content. Users are now working on the wrong version of data.
Result of having a cache: Lost productivity
Caches simply are not designed to support users in real-world environments. What is the point of purchasing and deploying caching servers that can't even handle standard operations like file name changes and edits to documents?
|
