Mit Blick auf Redis: Sind wir wirklich Entwickler, die etwas erfinden?

Mit Blick auf das Redis-Ökosystem frage ich mich noch einmal, ob ich wirklich selbstbewusst sagen kann, dass ich ein Entwickler bin, der etwas erfindet.

Die Entstehung von Key-Value-Storage

• Seit den 2000er-Jahren, mit dem Aufkommen des Web-2.0-Zeitalters, standen Webservice-Unternehmen vor der Herausforderung, enorme Nutzerzahlen zu bewältigen
• Um diesen gewaltigen Traffic zu verarbeiten, brauchte man keine großen, schönen Server, sondern kleine, günstige verteilte Systeme in großem Maßstab
• Zum Glück waren die meisten Datenstrukturen einfach (z. B. userid = 1234 abrufen)
• Dafür waren relationale Datenbanken (RDBMS) zu schwergewichtig, zu teuer und zu komplex
• Das CAP-Theorem trat auf den Plan
• Also konnte man, selbst wenn man Konsistenz aufgab, Verfügbarkeit und Geschwindigkeit gewinnen
• So entstand eine einfache Datenbank, der man einen key gibt und die einen value zurückwirft (Memcached-2003, Amazon Dynamo-2007)

Die Entstehung von Redis

• Im Heimatland der Pasta, Italien, betrieb ein Entwickler namens Salvatore Sanfilippo das Startup LLOOGG (ja, die Schreibweise von Log mit zwei O ist korrekt)
• LLOOGG bot einen Dienst zur Echtzeitverfolgung von Website-Besuchern an
• Es war zwar klein, hatte aber echte Nutzer
• Echtzeitanalyse war damals ziemlich schwierig
• Die Daten häuften sich → das bestehende RDBMS wurde immer langsamer → echte Reaktionsfähigkeit in Echtzeit war nicht mehr möglich
• Für Reaktionen in Echtzeit musste man Speicher im RAM nutzen → Memcached unterstützte damals nur einfaches GET und PUT in String-Form
• Man brauchte etwas erweiterte Dictionary-Funktionen wie INCR, DECR und LIST, aber es gab keine solche DB? → Verdammt, dann baue ich sie eben selbst
• So entstand die frühe Version, die auf einem extrem einfachen TCP-Server lief (keine hochtrabenden Features wie Cluster, AOF oder Replikation)

Die Weiterentwicklung von Redis

• Redis wurde nicht als Cache, sondern als Data-Structure-Store für Echtzeitverarbeitung geboren
• Doch die Leute begannen, es als Cache zu verwenden
• Die Anforderungen an Datenstrukturen jenseits von Cache-Anwendungsfällen bei den bestehenden Giganten (Facebook, Twitter, GitHub, Stack Overflow usw.) nahmen zu
• Von kleinen Funktionen wie Session-Speicherung, Verwaltung von Login-Token, Echtzeit-Zählern, Ranking-Systemen und Like-Zahlen begann eine schrittweise Einführung
• Verschiedene benötigte Funktionen und Datenstrukturen wurden evolutionär ergänzt (Sorted Set, HASH, Cluster, Persistenz ...)
• Am Ende wurde Redis zu einer flexiblen Plattform für Datenverarbeitung

Community, UX und die Philosophie der Entwickler

• Redis basiert auf der Philosophie, dass es viele Funktionen geben darf, aber nicht komplex sein soll
• Die offizielle Dokumentation bietet sofort ausführbare CLI-basierte Beispiele und klare Beschreibungen des Verhaltens
• Bei den intuitiven Befehlen (SET, GET, LPUSH, ZADD, HGETALL usw.) reicht ein kurzer Blick in die offizielle Doku, um direkt zu verstehen, was sie tun
• Diese Intuitivität ist nicht nur bequem, sondern senkt auch die psychologische Hürde gegenüber dem Werkzeug und steigert die Produktivität von Entwicklern
• Die Vielseitigkeit, die aus dieser Struktur entsteht, bringt Nutzern, Cloud-Anbietern und Open-Source-Mitwirkenden gleichermaßen Vorteile
• In einem Ökosystem, das aus gegenseitigem Nutzen besteht, etablierte sich Redis durch eine nicht erzwungene Wahl als De-facto-Standard für In-memory-Datenbanken

Mit Blick auf das Redis-Ökosystem

• Redis begann als Mittel, eine vielleicht ganz gewöhnliche Idee umzusetzen: Echtzeitanalyse von Besuchern
• Die Grenzen des bestehenden SQL-Ansatzes (langsam und teuer) wurden mit einem neuen Ansatz durchbrochen
• Es ging nicht um die Optimierung bestehender Regeln wie das Ausnutzen von Branchenkontakten, das Auspressen von Zulieferern, Hardware-Tuning oder Nutzungsbeschränkungen
• Stattdessen wurde eine neue Regel geschaffen: Speicher im RAM wird zum Kernelement der Datenbank
• Um Werkzeuge selbst zu entwerfen, bislang nicht vorhandene Abläufe vorzuschlagen und diese dann weltweit akzeptieren zu lassen, ist Grundlagenwissen für die Anwendung entscheidend
• Schon Amazon Dynamo, das zur Lösung des Problems der Warenkorb-Speicherung entworfen wurde, zeigt, dass komplexes Wissen über verteilte Systeme angewendet werden muss
• Wenn durch die freiwillige Wahl aller ein Industriestandard entsteht, werden enorme Mehrwerte und Arbeitsplätze geschaffen
• Das wird greifbar, wenn man an Redis-Fachkräfte, Hardware-Infrastruktur, Lerninhalte, Managed Services (AWS, Azure) und spezialisierte Lösungen (Redis Enterprise) denkt
• All das ist nicht durch staatliche Politik oder Gesetze entstanden, die irgendetwas von der Rettung einer bestimmten Industrie oder von KMU-Förderung erzählen

Wir sollten darüber nachdenken, ob wir nicht noch immer nur äußerlich ein entwickeltes Land sind und vielleicht mit einem Denken aus dem Industriezeitalter leben, während wir irrtümlich glauben, Entwickler seien Beschäftigte der Wissensdienstleistungsbranche.

• Können wir beweisen, warum Basistechnologien (z. B. Algorithmen) wichtig sind — und zwar durch Ergebnisse
• Haben wir eine Entwicklerkultur und ein Bildungssystem, in denen man Werkzeuge bauen kann, um Probleme zu lösen
• Alle sagen, man müsse eine Kultur fördern, die Scheitern zulässt — aber rege ich mich nicht selbst über die Fehler anderer auf oder beschimpfe sie sogar?
• Verstehen wir den echten Mehrwert der Wissensdienstleistungsbranche wirklich und können wir ihn hartnäckig weiterverfolgen

Ich rufe mir noch einmal in Erinnerung, dass ein echter Entwickler nicht einfach jemand ist, der Werkzeuge gut benutzt, sondern jemand, der — selbst wenn sie noch unausgereift sind — die benötigten Werkzeuge selbst entwirft, sie so gestaltet, dass andere sie leicht nutzen können, und dadurch das Ökosystem erweitert und Mehrwert schafft.

[roxie]

Ich wirke wohl wie ein Betrüger :(

[iolothebard]

Die Erfindung des Nutzens …