Infrastructure, plate-forme, disponibilité et levée de fonds


Si vous en êtes à votre troisième tour de table, que vous levez entre en 10 et 15 millions de dollars USD, pour une valo totale estimée entre 60 et 75 M$, pour une boite qui a un peu plus de deux ans et dont toute la bobosphère parle abondamment depuis plus d'un an, et que malgré celà, vous devez fermer purement et simplement votre service pendant plus de deux heures pour raison de "maintenance plannifiée" (sic), alors là, franchement, je vous dis : "Changez tout, repartez d'une feuille blanche, et optez pour une plate-forme et une techno qui sait *vraiment* monter en charge tout en restant facile à maintenir et à faire évoluer, et embauchez des bons codeurs", ie pour ceux qui ne l'auraient pas compris : abandonnez Ruby on Rails et passez à la plate-forme Microsoft...

TwitterPlannedMaintenance

Allons, tout ceci n'a pas de sens ! Mais est-ce que je suis le seul à trouver la disponibilité du service Twitter aussi déplorable ? Mettons à part le débat sans fin sur l'utilité du service, sa fiabilité et de sa disponibilité sont pathétiques, tout simplement.

Autre point à méditer : Quand on démarre un business ou un service basé sur les APIs d'un autre service dit "2.0", il est conseillé de regarder ces aspects de près... Je pense que Laurent a un avis éclairé sur la question 😉

Fin du message...

PS : Les avis au sujet de la capacité de RoR à monter en charge font débat. Je ne suis pas expert, mais je m'interroge 😉

Comments (3)
  1. Cher Christophe, je suis un peu déçu par ton post 🙂

    Sur le fond nous sommes d’accord, levée de fonds, qualité de service, montée en charge et compétente à maîtriser l’ensemble.

    Quand tu tires sur RoR je suis moins d’accord, RoR ne semble pas poser de problèmes à tout le monde, et je vois là comme un raccourci un peu facile 🙂

    Mais surtout, dans cette histoire de Twitter, le truc énorme qu’on oublie, RoR ou pas RoR, quelle que soit la techno, l’aberration la plus totale c’est le PULL a intervalle régulier de millions de clients là où tout devrait tourner en PUSH…!!!!

    Et c’est bien là le problème, la base même de Twitter est une énorme bêtise, le PULL et le POLL associé.

    Non ?

  2. odenis says:

    Je suis d’accord avec toi. d’autant plus que les solutions techniques pour résoudre ces problèmes existent.

    Mais alors pourquoi continuons tous à utiliser twitter ?;)

  3. A mon avis, le problème de twitter n’est pas du tout son langage de programmation, mais son architecture MySQL. Je lisais récemment qu’ils avaient un seul master et deux slaves…

    Pour un service aussi transactionnel et relationnel que twitter, il faudrait un *vrai* cluster MySQL *plus* tout un tas d’optimisation (sphinx, memcached…)

    Répartir du http c’est facile, suffit de mettre plus de serveurs et de synchroniser les fichiers ou d’utiliser un san. C’est clairement pas ruby qui pose problème, et ce serait pareil avec .net, php et même hardcodé en C++ dans le webserver.

Comments are closed.

Skip to main content