Frei3.de – Wie schwer ist es, eine Plattform zu entwickeln? Fallstudie: Unterschied zwischen den Versionen

Aus AutarkWiki
Zur Navigation springen Zur Suche springen
Zeile 23: Zeile 23:
 
Natürlich setzen wir dennoch auf moderne Web-Technologien, die hier gar nicht alle aufgelistet werden können, ohne in Technik-Jargon zu verfallen. Das heißt, wir verfolgen einerseits modular eine PIE-Philosophie „Proudly invented elsewhere“ – stolze Nutzung fremder Software – allerdings nur für nicht-kritische Software-Bereiche.
 
Natürlich setzen wir dennoch auf moderne Web-Technologien, die hier gar nicht alle aufgelistet werden können, ohne in Technik-Jargon zu verfallen. Das heißt, wir verfolgen einerseits modular eine PIE-Philosophie „Proudly invented elsewhere“ – stolze Nutzung fremder Software – allerdings nur für nicht-kritische Software-Bereiche.
  
Kritische, meist sicherheitsrelevante Bereiche auf frei3 entwickeln wir selbst. Dies geht soweit, dass wir die Zusammenarbeit mit Anbietern wie '''[https://www.it-daily.net/it-sicherheit/cloud-security/27153-warum-aws-s3-speicher-buckets-zum-sicherheitsproblem-werden-koennen AWS]''' oder Cloudflare vermeiden, um nicht auf deren guten Willen angewiesen zu sein, sondern notfalls unsere Software von einem zum nächsten Server-Anbieter oder in eigene Mini-Rechenzentren auslagern zu können. Wir verfolgen damit die NIH-Philosophie „Not invented here“ – dies ist die Vermeidung fremder und möglicherweise korrumpierbarer Software in kritischen Bereichen.
+
Kritische, meist sicherheitsrelevante Bereiche auf frei3 entwickeln wir selbst. Dies geht soweit, dass wir die Zusammenarbeit mit Anbietern wie '''[https://www.it-daily.net/it-sicherheit/cloud-security/27153-warum-aws-s3-speicher-buckets-zum-sicherheitsproblem-werden-koennen AWS]''' oder '''[https://www.techniknews.net/news/cloudflare-1-1-1-1-und-discord-down-problem-sorgt-fuer-fehler-beim-aufruf-von-tausenden-webseiten/ Cloudflare]''' vermeiden, um nicht auf deren guten Willen angewiesen zu sein, sondern notfalls unsere Software von einem zum nächsten Server-Anbieter oder in eigene Mini-Rechenzentren auslagern zu können. Wir verfolgen damit die NIH-Philosophie „Not invented here“ – dies ist die Vermeidung fremder und möglicherweise korrumpierbarer Software in kritischen Bereichen.
  
 
Hier beantwortet sich auch die Frage „Warum das Rad neu erfinden?“, denn diese muss richtiger heißen: „WANN das Rad neu erfinden?“ – Immer dann, wenn die bisherigen Räder nicht dem Anwendungsfall genügen! – Kann ich mit einem Autorad (mit Felge und Reifen) auch bequem das Auto lenken? – Nein, daher erfinde ich das Lenkrad. Kann ich mit dem Autorad oder Lenkrad in einem Getriebe Kräfte übertragen und transformieren? – Nein, daher erfinde ich das Zahnrad. Kann ich mit einem Autorad, Lenkrad oder Zahnrad ein leichtgewichtiges, von einer Person bewegbares Fahrrad bauen? – Nein, daher erfinde ich das Fahrrad-Rad mit Speichen. Die Liste ist lang. Ja, es lohnt sich, das Rad immer wieder neu zu erfinden, wenn es für einen neuen Anwendungsfall notwendig ist.
 
Hier beantwortet sich auch die Frage „Warum das Rad neu erfinden?“, denn diese muss richtiger heißen: „WANN das Rad neu erfinden?“ – Immer dann, wenn die bisherigen Räder nicht dem Anwendungsfall genügen! – Kann ich mit einem Autorad (mit Felge und Reifen) auch bequem das Auto lenken? – Nein, daher erfinde ich das Lenkrad. Kann ich mit dem Autorad oder Lenkrad in einem Getriebe Kräfte übertragen und transformieren? – Nein, daher erfinde ich das Zahnrad. Kann ich mit einem Autorad, Lenkrad oder Zahnrad ein leichtgewichtiges, von einer Person bewegbares Fahrrad bauen? – Nein, daher erfinde ich das Fahrrad-Rad mit Speichen. Die Liste ist lang. Ja, es lohnt sich, das Rad immer wieder neu zu erfinden, wenn es für einen neuen Anwendungsfall notwendig ist.

Version vom 1. November 2021, 08:38 Uhr

HagenGrell-Person-frei3-001.jpg

Wie schwer ist es, eine Plattform zu entwickeln?

Die Online-Plattform Twitter wird von vielen Nutzern als sehr leicht zu bedienen empfunden, daher müsste es doch auch leicht sein, Twitter zu programmieren, richtig? YouTube, Facebook und TikTok machen uns scheinbar spielend interessante Vorschläge, das müssten andere Plattformen doch auch können, oder? Als Nutzer der populäre Silicon-Valley- und mittlerweile auch China-Tech-Plattformen (TikTok, DLive, Trovo etc) sind wir häufig sehr verwöhnt, was die schiere Nutzerfreundlichkeit von modernen Online-Plattformen angeht. Doch was leicht aussieht, ist nicht leicht gemacht, meist im Gegenteil: Je intuitiver, bequemer und einfacher eine Plattform zu bedienen ist, desto mehr Gehirnschmalz und Arbeitsleistung steckte in ihrer Entwicklung. Eine Fallstudio zur Plattform
https://www.frei3.de.

Siehe: Hagen Grell

Mein Name ist Hagen Grell

und als Gründer, Projektleiter und Co-Entwickler eines Technologie-Startup-Unternehmens habe ich eine besondere Perspektive, was Schein und Sein moderner Internet-Plattformen betrifft. Als ich 2018 gemeinsam mit einem Backend-Entwickler begann, die Plattform frei3.de zu entwickeln (damals noch „FreiHoch3“ genannt), waren wir überschwänglich von jugendlicher Arroganz und Selbstüberschätzung. Die meisten Programmierer, die etwas auf sich halten, werden folgenden Sturm-und-Drang-Gedanken kennen: „Ok, das ist eine tolle Herausforderung, dieses Programm kann ich in einem Monat fertig schreiben, kein Problem für mich und meine Spitzenfähigkeiten“. Und ja, gelegentlich haben wir Glück und es handelt sich um ein schwieriges, aber beherrschbares, abgegrenztes Problem, welches innerhalb einer gewissen Zeit tatsächlich erledigt ist, obgleich aus einem Monat dann gern drei werden können .

Doch was passiert, wenn eine Aufgabe so groß ist und gleichzeitig so klein scheint, wie ein Eisberg, dessen 5% Spitze aus dem Wasser ragt und dessen 95% Masse sich bedrohlich unter der Oberfläche versteckt? Was passiert, wenn man obendrein ein Versprechen gegeben hat und diese Versprechen dazu öffentlich verkündete? Und was wenn man als Kirsche auf der Torte 68.000 Euro als Startfinanzierung sammelte und daher nicht mehr „aus der Nummer“ herauskommt? – Über die Höhen und Tiefen dieser Achterbahnfahrt, über Schweiß, Tränen und Glücksgefühle und über den goldenen Wert von Durchhaltevermögen möchte ich Ihnen heute berichten.

Fertig-Lösungen, Forking, Neuentwicklung

Als wir mit den Arbeiten an frei3 starteten, war uns klar, dass wir mit einer Neuentwicklung begannen. Fertig-Lösungen wie BuddyPress, BuddyBoss, Huthub oder PeerTube (letztere für Videoanwendungen) wären zwar eine Möglichkeit für die Anfangszeit gewesen, um binnen kurzer Zeit etwas vorlegen zu können (vergleichbar damit, eine fertige App einfach auf dem Smartphone zu installieren). Aber dies hätte uns später in massive oder sogar unlösbare Schwierigkeiten gebracht, wenn wir von zehntausende auf hunderttausende auf Millionen Nutzer würden „hochsklarieren“ müssen. Hochskalieren bedeutet, eine Anwendung mit all ihren komplizierten, ineinander verwobenen Funktionalitäten für eine plötzlich exponentiell höhere Nutzerzahl (zB in kurzer Zeit verzehnfacht) bereitstellen zu müssen. Das ist alles andere als trivial und hätte uns bei einer Fertig-Lösung das Genick brechen können.

Einfach neue Server dazu stellen und die Anwendung darauf installieren, ist technisch unmöglich, denn folgende Fragen müssen umfassend gelöst werden: (1) Wie kommunizieren die Server miteinander und „sprechen sich ab“, wie wird die Last verteilt? (2) Wie kommunizieren die Server abhörsicher unter höchstem Sicherheitsstandard? (3) Wie und wann werden die Datenbanken miteinander abgeglichen? (4) Wie werden die Daten auf den verschiedenen Servern redundant gespeichert, um Datenverlust zu vermeiden, wenn zB eine Festplatte ausfällt? (5) Wie wird Datenkonsistenz gesichert, wenn zB ein Serverzentrum in einem Teil der Welt ausfällt, aber die anderen Server noch erreichbar sind? (6) Wie geht man mit nötigen Wartungsarbeiten um und synchronisiert Updates auf allen Servern? (7) Wie versteckt und schützt man die tatsächlichen IPs der Server, um gegen Hacker-Angriffe gerüstet zu sein, insbesondere bei vielen Servern? (8) Wie garantiert man einen reibungslosen Traffic-Fluss für den Proxy, wenn die meisten Anbieter ab einem bestimmten verbrauchten Traffic-Volumen drosseln? – Und viele viele Fragen mehr.

HagenGrell-Person-frei3-012.jpg

Philosophie der frei3-Entwicklung

Eine eigene Anwendung hat auch den unschlagbaren Vorteil, komplett unter eigener Kontrolle zu liegen, sodass das Team frei und kreativ entwickeln kann und nur die eigene Fantasie und die Fantasie (und Wünsche) der Kunden die Obergrenze darstellen. Die Weiterentwicklung einer fremden App dagegen stößt nicht nur an mögliche Lizenzprobleme, sondern auch an „Legacy“-Probleme. Das heißt, sobald zB PeerTube einen Fork bekommt (Abtrennung von der Hauptentwicklungslinie für eigene Anpassungen) – nennen wir diesen Fork zum Beispiel „MeinPeerTube“ – wird es schwieriger oder mit der Zeit sogar unmöglich, Verbesserungen von PeerTube in MeinPeerTube zu übernehmen. Zudem müssen die MeinPeerTube-Entwickler sich so tief in die PeerTube-Software einlesen und werden so viel Code selbst schreiben, dass mit der Zeit (2-3 Jahre später) MeinPeerTube zu einer de facto kompletten Eigenentwicklung wird, die mit PeerTube nur noch wenig gemeinsam hat. Und die MeinPeerTube-Entwickler laufen sogar Gefahr, die grundsätzliche Kern-Software von PeerTube umschreiben zu müssen, wenn PeerTube software-architektonisch ein anderes Ziel hatte als die Entwickler von MeinPeerTube nun verfolgen.

Bei frei3 sind wir daher einen anderen Weg gegangen und haben von Anfang an auf eine Neuentwicklung gesetzt. Im Vergleich mit dem Forking-Ansatz ist dies analog zu einem Wettrennen zwischen einem Fahrrad (Forking) und einem LKW (Neuentwicklung). Das Fahrrad wird in der Anfangszeit viel schneller vom Fleck kommen und den LKW zunächst gnadenlos abhängen. Doch sobald der massige LKW Fahrt aufgenommen hat, wird er das Fahrrad letzlich überholen und (ver)trägt auch viel mehr Masse in seinem Innern (Nutzer, Funktionalität, Traffic etc), was für eine Online-Plattform entscheidend ist.

Natürlich setzen wir dennoch auf moderne Web-Technologien, die hier gar nicht alle aufgelistet werden können, ohne in Technik-Jargon zu verfallen. Das heißt, wir verfolgen einerseits modular eine PIE-Philosophie „Proudly invented elsewhere“ – stolze Nutzung fremder Software – allerdings nur für nicht-kritische Software-Bereiche.

Kritische, meist sicherheitsrelevante Bereiche auf frei3 entwickeln wir selbst. Dies geht soweit, dass wir die Zusammenarbeit mit Anbietern wie AWS oder Cloudflare vermeiden, um nicht auf deren guten Willen angewiesen zu sein, sondern notfalls unsere Software von einem zum nächsten Server-Anbieter oder in eigene Mini-Rechenzentren auslagern zu können. Wir verfolgen damit die NIH-Philosophie „Not invented here“ – dies ist die Vermeidung fremder und möglicherweise korrumpierbarer Software in kritischen Bereichen.

Hier beantwortet sich auch die Frage „Warum das Rad neu erfinden?“, denn diese muss richtiger heißen: „WANN das Rad neu erfinden?“ – Immer dann, wenn die bisherigen Räder nicht dem Anwendungsfall genügen! – Kann ich mit einem Autorad (mit Felge und Reifen) auch bequem das Auto lenken? – Nein, daher erfinde ich das Lenkrad. Kann ich mit dem Autorad oder Lenkrad in einem Getriebe Kräfte übertragen und transformieren? – Nein, daher erfinde ich das Zahnrad. Kann ich mit einem Autorad, Lenkrad oder Zahnrad ein leichtgewichtiges, von einer Person bewegbares Fahrrad bauen? – Nein, daher erfinde ich das Fahrrad-Rad mit Speichen. Die Liste ist lang. Ja, es lohnt sich, das Rad immer wieder neu zu erfinden, wenn es für einen neuen Anwendungsfall notwendig ist.

Quellen / Weblinks

[1] Eigenaussage von Hagen Grell im Gespräch mit der Redaktion