{C++ etc.}

Latest Posts
Home | C++ Posts | Linux Posts | Programming Posts | Issue Tracking Posts

Monday, July 14, 2008

Scaling - Technology vs. Services

I just read a blog post by Dare Obasanjo which focused on the importance (or lack of it) when dealing with rapid scaling. Here's and excerpt from it:

If someone tells you "technology X doesn't scale" without qualifying that statement, it often means the person either doesn't know what he is talking about or is trying to sell you something. Technologies don't scale, services do. Thinking you can just sprinkle a technology on your service and make it scale is the kind of thinking that led Blaine Cook (former architect at Twitter) to publish a presentation on Scaling TwitterFail Whale begs to differ. which claimed their scaling problems where solved with their adoption of memcached. That was in 2007. In 2008, let's just say the Fail Whale begs to differ.

If a service doesn't scale it is more likely due to bad design than to technology choice. Remember that.

You could find the full entry here.

I have to contradict. Choosing the right technology can have a significant impact on handling ever increasing data loads. Scaling one's service (as Dare has said) is simple if a proper design has been adopted at an early stage. But one has to take into consideration the cost factor. Hardware and bandwidth levy a recurring toll on the budget and in most instances it's not feasible to scale in terms of expanding your service horizontally.
Choosing the correct technology for a project is also a critical design decision and would aid in handling a bigger load on one's current infrastructure. Prot buffs are better than XML when you consider the bandwidth and overhead on processing. Big tables are supposed to be faster than relational data bases for in most common cases. Our company develops distributed systems which delas with massive amounts of data and we optimize our processes by adopting proper data structures, light-weight messaging protocols, minimal logginh etc. to achive the best performance numbers before we even think about scaling our services.
In conclusion, I think it's important to adopt lighter, faster technologies when designing a system as well as making it scalable at the service level.

No comments: