Why spend a lot of time and work when a simple hardware upgrade will work ?
And you are deluding yourself if you think that the sharding model you are going to implement is not "only buying you time" and you will have to do additional engineering over time if you keep growing.
Same for manual cleanups and stuff. If you need to fix half a dozen source files, just wince and do it manually. If you need to fix thousands of source files, it's probably time to write a parser & refactoring browser and then use that.
> need to be upgraded to SSDs to save your 20%, it might be
> worth looking into software optimization.
However the margin is still quite high. I've replaced twice big EMC SAN arrays with 8 SSDs, and the performance gain was 300 to 400% (different customers, different applications).
SSDs envelope is usually quite narrow, but if you hit the sweet spot it's such a game changer than it beats everything else.
Not saying what they did was wrong but there's still the option of automating those guys' tedious tasks and finding them something more useful to do.
Kudos for acknowledging the benefits of their approaches, but I feel like it's the architect's responsibility to reconize the most cost effective solution for the context at hand. How many problems aren't we hearing about that could have been solved with a new network switch instead received an application rewrite with an SOA architecture?
Ideally, you want effectiveness and efficiency. If you can't have both, you need to be effective before you are efficient, as both of the author's analogies make clear.
I thought he was insane. But It's funny, it was almost always the case. Throwing another server at the problem turned out to be way more cost-effective than having to go back to engineering, spend 40 hours optimizing and another 40 doing regression testing.
