Sunday
Apr052009
At Some Point the Cost of Servers Outweighs the Cost of Programmers
Sunday, April 5, 2009 at 7:12AM 
This is the intriguing quote by Bill Venners in an interview with Twitter's Alex Payne on Twitter's heretical switch from a pure Ruby stack to a Ruby on Rails stack on the front-end and JVM/Scala on the back-end:
So performance was also one of the problems with JRuby, which I [Bill Venners] think helps explain better why they'd [Twitter] prefer Scala over Ruby or JRuby for some things.
I have often heard Rubyists say that although Ruby is slower than Java, for many things it is plenty fast enough, and they are right. The logic goes further, saying that servers are cheap, and programmers expensive, so it makes sense to tradeoff some runtime performance for programmer productivity. And I think that's very often true too, but not always. If you have enough traffic, at some point the cost of servers outweighs the cost of programmers. I'm not sure whether Twitter is past that point, but they get a lot of traffic. And frankly this isn't an intrinsic tradeoff. Other dynamic languages are faster than Ruby, and Scala is too. And people can be quite productive in these other languages too, including Scala.
I feel Alex's Max Payne. You might wonder why the geekosphere cares so passionately which technology stack Twitter uses? Well, it's Twitter and it's Ruby on Rails. That's like the Lindsay Lohan and Samantha Ronson of tech buzz. It creates it's own self-sustaining posting reaction. Boom!
It took some giant cajones to switch from a well defended platform like Ruby on Rails to an obscure language like Scala. Few people would have been brave enough to pull the trigger on that decision.
Twitter didn't take this large leap out of ignorance or incompetence. Twitter's Steve Jenson said they spent several weeks going over our options, running extensive load tests, and presented our findings to the team at each stage. We did our due diligence.
They did the work and came to conclusions valid for their situation. They have to follow their own bliss. They aren't telling you to use Scala. They aren't telling you not to use Ruby. Have at it. But they have chosen the path less traveled and seem happy with the direction they are heading. If you aren't happy with their decision then that's a you problem, not a them problem.
This points out for me the evolving nature of the two tier web: a client tier and a back-end tier accessed only via an API. That back-end tier can be implemented in anything at all. Twitter likes the JVM for it's undeniable performance, reliability, and scalability. They may like Scala because it has a lot of cool features, is concise, has static typing, performs well, and is a pleasure to develop in.
When people jumped with a happy little grin on their face to Ruby, they loved a lot of things about Ruby that helped them make that decision to switch. Maybe Scala is cool, effective, and fun to use too?
So instead of worrying how the homeboys have ever so indirectly dissed Ruby, maybe it's worth taking a look at Scala to see if it's actually any good?
As a start try Bill Venners on the rise of Scala. It's a great overview of Scala and why it's a worthy next evolution. Then maybe take a peek at First Steps to Scala. And if you want to take a look at some real-life code try Kestrel - tiny queue system based on starling.
Knowing only the vaguest bits about Scala before my own little exploration, I come out impressed and interested. I like a lot of things Bill had to say: Scala means scalable language as in it scales to different sized tasks and domains; Scala's static typing is valuable, especially in a team project; Scala has the feel of a scripting language, but can also work as a systems language; Scala is an artful blend of a fully Object and fully Functional language; Scala supports imperative programming, but with a functional bent; Scala can express more in types than Java so you get more rigorous type checking; Scala is concise so can say more with less; Scala treats libraries like creating internal DSLs; Scala helps programmer productivity like Ruby and Python.
Sounds like Scala is worth a deeper look to me. Can't we all just get along?
Well, that's not how this post started at least. It started with Bill's refreshingly anti-establishment statement: If you have enough traffic, at some point the cost of servers outweighs the cost of programmers. This is an idea we don't hear much of anymore in this era of abundance. Servers cost real cash though, especially for bootstrappers and the truly humongous. So if you can cut your cash requirements by putting in a little programmer elbow grease, that makes a lot of sense to me. Performance still matters.
Reader Comments (8)
Glad to see a few out there who aren't part of this herd that the Internet has created. There is nothing more ridiculous than the thousands of noobs who start work every year and start peddling the secondhand information they gleaned from someone's blog. Okay, okay, not just the noobs but even the gullible "seasoned" ones. LOL
I think Scala incorporates some great "academic" language ideas (functional programming and type inference) with a pragmatic implementation (leveraging the JVM and Java libraries). But if people are looking beyond Java because the language has grown too baroque, then Scala might not be the answer: Scala has so many language ideas and features busting out its seams, it seems like the snobby Frankenstein child of J2EE and Perl.
Why do you use "LOL" ?
This post is mistitled - I was hoping for a discussion about management costs of servers, complexity of deployments or issues around having a mass number of servers to manage. Operations cost verse Engineering costs.
Instead its a scala vs. ruby argument which has little to do with costs of programming verse cost of servers.
Those would have been good angles Marcus. And sounds like a good article for you to write :-) But I was more taken by the machines are cheap take on languages and frameworks.
On a similar vein, Google is currently pumping money into Python development, with a view to making it 5 times (!) faster in the next year or so. They also wish to remove that perennial pest, the Global Interpreter Lock. Again, this is a project which will cost them a few million in development, but will probably save them millions a month in servers; they use Python quite a bit.
"If you have enough traffic, at some point the cost of servers outweighs the cost of programmers."
True, but the calculations are somewhat more complicated as you're (hopefully) putting in servers to enable more customers and thus drive revenue. In essence, scaling of an architecture isn't just about managing performance.
You are paying for lots of servers but that's put up against making more revenue. What's required then, is cost-effective scaling of a system which might in some cases, drive the need to change the language/platform used for various components.
But can you sell old programmers on EBay or CraigsList?
Believe me, I had this boss once .....