Comment réduire de 100x le coût de construction d’un Mastodon à l’échelle de Twitter

• Red Planet Labs a développé depuis zéro une instance Mastodon à l’échelle de Twitter avec seulement environ 10�00 lignes de code
  • Soit 100 fois moins que les quelque 1 M de lignes de code qu’il a fallu à l’origine pour construire le produit de Twitter
• L’instance Mastodon a été construite sur une nouvelle plateforme appelée Rama
  • Rama repose sur un modèle qui unifie calcul et stockage, permettant de construire n’importe quel backend à n’importe quelle échelle avec 100 fois moins de code
  • Une plateforme généraliste pour construire des backends d’application, programmable via une API Java pure
• La construction a nécessité 9 personnes-mois (person-month). C’est bien plus rapide que Twitter avec ~200 personnes-années, ou Threads avec 25 personnes-années
• Bien beaucoup plus petite que l’implémentation officielle de Mastodon, elle peut malgré tout passer à l’échelle de Twitter
• Red Planet Labs publiera dans la semaine une version de Rama que tout le monde pourra télécharger et utiliser, puis open sourcera totalement l’implémentation Mastodon deux semaines plus tard
• L’entreprise prévoit également de lancer bientôt une bêta privée donnant accès à la version complète de Rama

Instance Mastodon de Red Planet

• Hébergée sur https://mastodon.redplanetlabs.com, elle inclut toutes les fonctionnalités de Mastodon.
• Pour montrer l’échelle de l’instance, Red Planet Labs exploite 100 M de comptes bots qui publient en continu des statuts, réponses, boosts et favoris
• L’instance Mastodon peut traiter 100 M de bots publiant 300 messages par seconde, ce qui démontre sa scalabilité

Rama

• Se compose de 4 concepts
  • Depot : stockage de données distribué et répliqué
  • ETL : streaming en micro-lots
  • PStates (Partitioned State) : indexation universelle
  • Query : topologie de requête
• Rama est extensible linéairement, permet d’ajouter des ressources selon les besoins et atteint la tolérance aux pannes en répliquant toutes les données et en mettant en œuvre un basculement automatique

[sftblw]

"We’ve implemented every feature of Mastodon from scratch, including:"

On dirait que ce n’est pas vraiment Mastodon. D’après la description, cela ressemble plutôt à un clone maison. Ça semble se positionner comme une implémentation « compatible », similaire à "Wildebeest" de Cloudflare ou à l’implémentation open source GoToSocial. Le code source devrait être publié plus tard...

Le front-end, c’est soapbox

Je me demande si Mastodon gGmbH ne va pas leur chercher des noises

[kuroneko]

J’ai essayé d’en faire un résumé, mais je n’ai pas réussi à comprendre, donc j’ai fini par laisser tomber...
Je me suis dit que ce serait bien de prendre le temps plus tard pour le comprendre tranquillement.

Mais je ne sais pas vraiment si ça pourrait être rentable.

[xguru]

Moi aussi, j’ai essayé de lire plus en détail la seconde partie, mais le texte ne se lit pas très bien.
J’ai l’impression qu’en dehors de la technique, la documentation n’est pas leur point fort.
Dès l’explication des quatre concepts importants, je me suis dit un peu « hein ? » T_T

[xguru]

La comparaison au nombre de lignes de code me paraît un peu forcée… mais ça a clairement bien attiré l’attention. Il y a aussi une explication extrêmement longue sur la plateforme Rama et l’implémentation interne de leur propre instance. Au final, j’ai l’impression qu’il faudra voir une fois que ce sera réellement sorti.

[GN⁺]

Commentaires sur Hacker News

• L’article traite de la réduction des coûts et de la complexité du code lorsqu’on fait passer le réseau social Mastodon à une échelle comparable à celle de Twitter, avec un facteur 100.
• Certains lecteurs remettent en question la comparaison entre les 10 000 lignes de code de Mastodon et le million de lignes de code environ de Twitter, en affirmant que Mastodon offre bien moins de fonctionnalités et qu’ajouter des fonctions comme la prise en charge de la vidéo distribuée en temps réel à grande échelle ferait fortement grossir la base de code.
• Il existe un certain scepticisme face à l’affirmation selon laquelle 100M de bots publieraient 3 500 messages par seconde pour illustrer l’échelle, certains lecteurs estimant que ce n’est pas suffisant et se demandant s’il s’agit d’un chiffre par bot ou au total.
• Certains lecteurs disent avoir du mal à comprendre les détails techniques du billet, estimant qu’il suppose une base de connaissances partagée et qu’il aurait besoin d’explications et de comparaisons plus claires.
• La mesure de l’« échelle Twitter » en nombre de tweets par seconde est remise en question, certains lecteurs suggérant qu’un indicateur plus réaliste serait le nombre de mises à jour par seconde reçues par les utilisateurs finaux qui suivent ces tweets.
• Le billet est salué pour la richesse de ses analyses et pour son abstraction, qui réduit la complexité du développement d’applications modernes à un assemblage de structures de données.
• Certains lecteurs expriment des inquiétudes face à l’idée que les développeurs s’appuient sur une plateforme propriétaire de startup à code source fermé pour toutes les fonctionnalités, en assumant le risque de changements ou d’interruptions.
• Une certaine confusion entoure la question de savoir si les 10 ans passés à construire la plateforme Rama doivent être comptés dans le temps nécessaire au développement de la démonstration technique.
• Certains lecteurs se disent enthousiastes à propos de la documentation à venir pour Rama, tout en exprimant des réserves face à la proposition d’un nouveau paradigme de programmation.
• Les performances de l’instance Mastodon citée en exemple sont saluées pour leur réactivité, mais il est souligné qu’elle n’implémente pas la recherche plein texte tant que l’utilisateur n’est pas mentionné par tag.