Scalability: where engineering counts

May 22nd, 2008 by Benjamin Kuo

There’s been more than enough random speculation (and complaining) on the various blogs on why the popular Twitter instant messaging service has been crashing (it seems like it’s been down more than it’s been up, and the site’s technical team has even said that they’re not sure what’s happening.)

I don’t have any insights into twitter, but, having been on the engineering side of things (as a software architect) I do know that their choice of Ruby On Rails — the interpreted language they use at their back end for the service — must have been the worse possible choice if you really expected your service to take off.

For the non-technical (which seems to be most bloggers) — an interpreted language is one which isn’t compiled directly into the native code of the machine you’re running on, but instead is parsed line-by-line (in the English-like language) every time it is run. Conversely, a compiled language is translated directly into machine code — in the native instructions/bits/bytes of the processor. The speed difference is gigantic.

There’s been some speculation (by the clearly nontechnical) that the firm should have used something like C or Java. C might be a choice, but (having built large scale projects) with Java, Java is just as slow (or slower — just ask any Java programmer about problems with garbage collection) as Ruby On Rails as an environment. Interpreted languages — whether that’s Ruby, Java (yes, that’s interpreted too), Python, Perl, and PHP, inherently are far removed from the systems they are running on than compiled languages (C++ and C). That’s usually fine — the ease of use, libraries, and tools they offer make for much more rapid development– but when you’re talking about really scaling an application they face a lot of challenges.

Regardless of the right choice of application development for Twitter, the key point to take in all the back and forth about scalability — is your engineering team counts. I’ve talked with many non-technical founders who have considered completely outsourcing all of their development (to a third party, to an outsourcer in India/China/Prague/etc.); who do not have a technical co-founder, and I can only shake my head — if you are in a software driven environment, including a web-driven service, you absolutely need to have a team which knows how to deal with issues of scalability, performance, and stability. This is an area where years of experience — and not just hacking around with Java in school — is important. Even though you might be able to create a startup nowadays with six people and six months–using something like Ruby On Rails– going from a small test application and a few hundred users to thousands and thousands of people is no picnic.

Leave a Reply

You must be logged in to post a comment.