Wille Faler’s Buzzword Bingo

In my previous post, I made the guess/assertion that Twitters scaling problems stem from the high likelihood that it is architected with web technologies, when it is fundamentally a messaging system. Seems I was right - Twitter themselves are acknowledging this on their dev site:

Twitter is, fundamentally, a messaging system. Twitter was not architected as a messaging system, however. For expediency’s sake, Twitter was built with technologies and practices that are more appropriate to a content management system.

TechCrunch has a post about Twitter, the group messaging service startup that has had a lot of scaling and stability problems recently. This quote caught my attention:

Twitter is unique in that it needs to parse a large number of messages and deliver them to multiple recipients, with each user having unique connections to other users.

What’s so unique about that? Telecoms, banks and other financial institutions have been doing it for the last 20 years or so.
I don’t know much about Twitter, apart from the fact that RubyOnRails is the central technology in the platform. That leads me to believe that Twitter is essentially built like a webapp - synchronous calls all the way with a database at the end. This alone will cause a world of problems for what is essentially a messaging application. To boot, it won’t be helped one bit by the fact that RubyOnRails is known to have some fundamental issues when it comes to scaling and performance, the fact that it is a web technology and provides little to no functionality for messaging doesn’t help either.

The solution to Twitters woes is quite simple (well, in theory, not to implement after the fact) - use asynchronous messaging based middleware heavily. It’s what everyone else facing similar challenges have done for years, and done successfully. The root of the problem probably lies more in the fact that Twitter have had web development people applying web technologies and web practices on something that should effectively have been a messaging platform from the get-go.

The Register reports that Barclays Capital is cutting the pay of their contractors by 10% over the board, those who do not accept the pay cuts will be allowed to work out their notice period.

I can sympathize with Barclay Capitals wish to slash 10% of contractor costs, but the way they are going about it is rather inept: they will annoy and alienate just about every contractor they use, which will hardly do wonders for morale, productivity and retention of high value individuals.
The fact is, some contractors may be grossly underpaid compared to the value they bring as it is, whereas others may be grossly overpaid or even surplus requirements. Why not try to identify the overpaid or surplus requirements contractors instead of using such a blunt instrument to cut cost?

..but then again, doing shrewd business moves can sometimes be hard work, and given the predicament that necessitated this move in the first place, shrewd business moves are probably not very high up on their agenda..

(Point of note: I do not contract for Barclays Capital, nor have I ever been affiliated with them in any shape or form).