Wie die Kosten für den Aufbau eines Mastodon in Twitter-Größe um das 100-Fache gesenkt wurden

• Red Planet Labs hat mit nur etwa 10.000 Zeilen Code eine Mastodon-Instanz in Twitter-Größe von Grund auf entwickelt
  • Das sind 100-mal weniger als die rund 1 Mio. Codezeilen, die Twitter ursprünglich zum Aufbau des Produkts verwendet hat
• Die Mastodon-Instanz wurde auf einer neuen Plattform namens Rama aufgebaut
  • Rama ist ein Modell, das Berechnung und Speicherung integriert und es ermöglicht, Backends jeder Größenordnung mit 100-mal weniger Code zu erstellen
  • Eine universelle Plattform zum Aufbau von Anwendungs-Backends, die über eine reine Java-API programmiert werden
• Der Aufbau erforderte 9 Personenmonate. Im Vergleich zu Twitter mit etwa 200 Personenjahren und Threads mit 25 Personenjahren ging es deutlich schneller
• Obwohl sie viel kleiner als die offizielle Mastodon-Implementierung ist, kann sie auf Twitter-Größe skalieren
• Red Planet Labs wird innerhalb einer Woche eine Version von Rama veröffentlichen, die jeder herunterladen und verwenden kann, und plant zwei Wochen später, die Mastodon-Implementierung vollständig Open Source zu machen
• Das Unternehmen will in Kürze eine Private Beta starten, die Zugang zur Vollversion von Rama bietet

Mastodon-Instanz von Red Planet

• Sie wird unter https://mastodon.redplanetlabs.com gehostet und enthält alle Funktionen von Mastodon.
• Um die Größe der Instanz zu demonstrieren, betreibt Red Planet Labs 100 Mio. Bot-Accounts, die kontinuierlich Statusmeldungen, Antworten, Boosts und Favoriten posten
• Die Mastodon-Instanz kann 100 Mio. Bots verarbeiten, die 3.500 Posts pro Sekunde veröffentlichen, und belegt damit ihre Skalierbarkeit

Rama

• Besteht aus 4 Konzepten
  • Depot: verteilter replizierter Datenspeicher
  • ETL: Micro-Batch-Streaming
  • PStates (Partitioned State): universelle Indizierung
  • Query: Query-Topologie
• Rama ist linear skalierbar, kann bei Bedarf um Ressourcen erweitert werden und erreicht Fehlertoleranz durch Replikation aller Daten und automatisches Failover

[sftblw]

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

Das scheint eher kein Mastodon zu sein. Der Beschreibung nach wirkt es eher wie ein eigener Klon. Es scheint eher die Position von „kompatibel“ einzunehmen, ähnlich wie Cloudflares "Wildebeest" oder die Open-Source-Implementierung GoToSocial. Der Quellcode soll wohl noch veröffentlicht werden ...

Das Frontend ist soapbox

Ich frage mich, ob Mastodon gGmbH da nicht Einwände erheben wird

[kuroneko]

Ich wollte das eigentlich zusammenfassen, habe es aber nicht verstanden und es dann am Ende doch gelassen...
Ich dachte mir allerdings, dass es gut wäre, mir später einmal Zeit zu nehmen und es in Ruhe zu verstehen.

Aber ob das wirklich Geld einbringen wird, weiß ich nicht so recht.

[xguru]

Ich wollte den späteren Teil auch etwas genauer lesen, aber der Text ließ sich nicht besonders gut lesen.
Unabhängig von der Technik wirkt es auf mich so, als wären sie nicht besonders gut im Dokumentieren.
Schon bei der Erklärung der vier wichtigen Konzepte dachte ich irgendwie: Hä?

[xguru]

Ein Vergleich anhand der Anzahl der Codezeilen scheint etwas schwierig zu sein, aber Aufmerksamkeit hat es definitiv erzeugt.
Es gibt eine sehr ausführliche Erklärung zur Rama-Plattform und zur internen Implementierung ihrer eigenen Instanz.
Ich denke, man wird es erst wissen, wenn es tatsächlich herauskommt.

[GN⁺]

Hacker-News-Kommentare

• Der Artikel behandelt die Verringerung von Kosten und Code-Komplexität beim 100-fachen Hochskalieren des sozialen Netzwerks Mastodon auf Twitter-Größe.
• Einige Leser stellen den Vergleich zwischen Mastodons 10.000 Codezeilen und Twitters etwa 1 Million Codezeilen infrage und argumentieren, dass Mastodon deutlich weniger Funktionen habe und dass das Hinzufügen von Features wie groß angelegter verteilter Echtzeit-Video-Unterstützung die Codebasis stark vergrößern würde.
• Es gibt Skepsis gegenüber der Behauptung, dass 100M Bots mit 3.500 Posts pro Sekunde die Größenordnung demonstrieren; einige Leser halten das für nicht ausreichend und fragen sich, ob dies pro Bot oder insgesamt gemeint ist.
• Einige Leser haben Schwierigkeiten, die technischen Details des Beitrags zu verstehen, und schlagen vor, dass der Beitrag ein geteiltes Wissensfundament voraussetzt und klarere Erklärungen sowie Vergleiche benötigt.
• Es wird infrage gestellt, ob „Twitter-Größe“ anhand der Anzahl von Tweets pro Sekunde gemessen werden sollte; einige Leser schlagen vor, dass die Zahl der Updates pro Sekunde für Endnutzer, die Tweets verfolgen, ein realistischeres Maß sei.
• Der Beitrag wird für seine detaillierten Einblicke und für die Abstraktion gelobt, die die Komplexität moderner App-Entwicklung auf eine Mischung aus Datenstrukturen reduziert.
• Einige Leser äußern Bedenken gegenüber dem Vorschlag, dass Entwickler für alle Funktionen auf die Closed-Source-Plattform eines Startups angewiesen sein sollen und dabei das Risiko von Änderungen oder Ausfällen in Kauf nehmen.
• Es gibt Verwirrung darüber, ob die 10 Jahre, die für den Aufbau der Rama-Plattform benötigt wurden, in die Zeit einbezogen werden sollten, die für die Entwicklung der technischen Demo aufgewendet wurde.
• Einige Leser zeigen sich begeistert von der bald erscheinenden Dokumentation zu Rama, äußern aber auch Bedenken gegenüber dem Vorschlag eines neuen Programmierparadigmas.
• Die Performance der als Beispiel genannten Mastodon-Instanz wird für ihre gute Reaktionsfähigkeit gelobt, zugleich wird jedoch darauf hingewiesen, dass sie keine Volltextsuche implementiert, es sei denn, der Nutzer wird getaggt.