There was a nice discussion this week at the Network World forums:
http://www.networkworld.com/community/?q=acceleration
We listened to the hardware acceleration appliance guys, and here is what we had to say in that “classic” debate:
Software vs. Hardware? (From the Software Side)
Reviewing this discussion (“Hardware vs. Software“ on this link), there are many interesting points, but coming from the smaller/mid-market and software side of the fence, we would like to chime in from Port80 Software (developer of software tools for HTTP compression and cache control on Microsoft IIS Web servers).
Based upon our experience, when it comes to software, one benefit you get is taking advantage of existing CPU/hardware investment. In the case of accelerating Web applications, it is often found that the Web server is network-bound and not CPU-bound. Using spare cycles on the origin server seems a perfectly good idea and often frees up network connections because of being able to close connections which have been ack-ed faster than they would be non-accelerated. ROI, of course as other posters mention, should also include that sunk $$ and time value -- and use of that asset as well.
We would point out that most appliances are just Linux boxes which are running some proxy, mod_gzip, etc. Form factor and management is certainly improved, but let's get real, this isn't silicon-based in nearly any case (chip-level application of these performance enhancements would be a real appliance advantage, wouldn’t it?).
Further, there have been some issues with appliances becoming bottlenecks for performance themselves, particularly in the case of HTTP compression, given that you are now routing all your connections thru your single (or multiple Web front ends). This isn't conjecture and was actually discussed in the recent Network World article by David Newman (http://www.networkworld.com/reviews/2006/011606-wfe-intro.html).
On the flip side of the bias, software suffers from many of the points made, management and deployment being large ones and, in some cases, suitability. For example, doing connection pooling in software at an origin server doesn't make much sense…
In short, this thread shouldn't be Software vs. Hardware, but could instead be more useful to readers/evaluators if we focused on the best place(s) to do a particular task and at what ROI to accomplish the best blend of bandwidth reduction, latency improvement, cost savings, etc. that readers are going for. We should be honest about where hardware works, if you can afford it and have the type of network architecture that would justify the cost -- and where software point solutions also add value cost-effectively and contribute to network optimization without configuration or management headaches.
What do you folks think?
Have a great weekend,
Port80