The news that Twitter's lead architect Blaine Cook and Lee Mighdoll, VP engineering have left should be no surprise. Let's be blunt. Despite the neutral language used in various posts, they were fired. One has to wonder whether Jack Dorsey is next, especially as he doesn't seem to understand the problems of scaling the service.
In the past, Twitter blamed Joyent for its outage problems but I suspect that's not true from things I've been told under non-disclosure. More to the point, how can you credibly assert that a service architecture is responsible when outages continue long after you've allegedly moved on? As Mike Arrington observes:
Cook was directly responsible for scaling Twitter, and he very much failed in his job. A year ago he spoke at the Silicon Valley Ruby Conference about scaling Rails applications. His presentation suggested Twitter’s problems were behind them, but in fact some of their biggest stumbles hadn’t occurred yet.
Twitter's problems are not difficult to understand though it is fair to say the solutions are in the realms of rocket science. From what I know and have heard, the failures arise out of the way Twitter was orginally architected combined with in-fighting about how things should be taken forward. Dumping the two people most responsible for that situation is only part of the answer. A fundamental rethink is necessary. To quote Curt Monash from a thread on Scripting News earlier in the year:
Complex event/stream processing (CEP) could easily handle it at a central site, and then the rest is standard redundancy. What StreamBase does for Wall Street or the spooks is 1-2 orders of magnitude more demanding than what Twitter needs today. (Coral8 can do the same things.) That's a lot of headroom. http://www.dbms2.com/2008/01/16/twitter-could-e... has some details.
At the time, Larry Dignan questioned whether Twitter needs to be reliable, leaning towards 'yes.' Earlier in the week, Arrington went off the deep end declaring that Twitter's persistent outages may not matter. As we now know, they matter to Twitter's investors who at least recognize that any hope of monetizing the service rests upon reliability at scale. Therein lies the salutary lesson for all application developers working in this 'good enough' service world. If you don't get it right from day one, admit that early, change and move on.
In the meantime, one has to wonder whether the current management changes are too little, too late. Only time and the adoption of alternative competitive services like FriendFeed will tell.
UPDATE: Larry Dignan offers this opinion:
The big question: If Twitter were built today would it have used the same infrastructure? If the answer is no that means Twitter in its short life is already saddled with legacy technology and that’s a project management nightmare. You only get one shot at an IT greenfield and Twitter may have guessed wrong.