| |||||||||||||
Scale Fail (part 2) Hardware often works ...Scale Fail (part 2) Hardware often works ...Posted May 20, 2011 15:43 UTC (Fri) by jberkus (subscriber, #55561)In reply to: Scale Fail (part 2) Hardware often works ... by mrjk Parent article: Scale Fail (part 2)
Mrjk,
First, you make a lot of good points.
The problems with the "just throw hardware at it" solution are two-fold:
1. The cost balance is often extremely disproportionate. That is, it's frequently the case that $20,000 worth of smarter software will save you $200,000 worth of additional hardware, rack space, cooling and sysadmin time.
2. In the fairly common cases where dumb software consumes geometrically increasing quantities of hardware for a linearly increasing workload, the "more hardware" solution is a very temporary measure.
Obviously there are cases where the tradeoff of "let's just buy more hardware" is completely viable, and I've implemented a few. But that only works if you're making an informed tradeoff, where you actually calculate the costs and capabilities of each path.
(Log in to post comments)
Scale Fail (part 2) Hardware often works ... Posted May 22, 2011 3:56 UTC (Sun) by willy (subscriber, #9762) [Link]
One extreme example (in the opposite direction :-)
http://thedailywtf.com/Articles/That-Wouldve-Been-an-Opti...
Scale Fail (part 2) Hardware often works ... Posted May 26, 2011 1:30 UTC (Thu) by adavid (subscriber, #42044) [Link]
Twice in my career as a sysadmin I have pushed back on applications that wanted to spend more money on hardware to rush a project that had major memory problems. One project saved one hundred thousand dollars and the other saved nearly a million dollars by tracking and fixing memory leaks.
|
|||||||||||||