RethinkDB: Warum wir geschlossen haben

Die Übersetzung des Artikels wurde mit Genehmigung des Autors veröffentlicht.

Als wir bekannt gaben, dass RethinkDB heruntergefahren wird, habe ich versprochen, eine posthume Kritik zu schreiben. Ich habe einige Zeit gebraucht, um die Erfahrung zu überdenken, und jetzt kann ich es klar sagen.

Im HN-Diskussionsthread beschrieben die Leute viele Gründe, warum RethinkDB versagt hat, angefangen von der unerklärlichen Perversion der menschlichen Natur über die listigen Machenschaften der MongoDB-Vermarkter bis hin zum Versagen, ein erfahrenes Team aufzubauen, das bereit ist, in den Markt einzutreten, was mit der mangelnden Unterstützung für numerische Typen endet, die größer als 64-Bit-Float sind. Ich habe die Kommentare in der Liste der vorgeschlagenen Fehlergründe zusammengefasst.

Einige von ihnen haben etwas Wahres, aber sie sind eher Symptome als Ursachen. Zum Beispiel ist die Aussage, dass wir nicht gelernt haben, wie man einen finanziellen Gewinn erzielt, oberflächlich. Diese Aussage beleuchtet nicht die Gründe, warum wir nicht erfolgreich waren.

Rückblickend komme ich zu dem Schluss, dass zwei Dinge schief gelaufen sind: Wir haben uns für einen schwierigen Markt entschieden und das Produkt nach den falschen Kriterien für die Nützlichkeit für den Benutzer optimiert. Jeder dieser Fehler hat wahrscheinlich den Wert von RethinkDB um eine oder zwei Größenordnungen verringert. Wenn wir eines dieser beiden Dinge richtig machen würden, würde RethinkDB die Größe von MongoDB erreichen, und wenn wir beide Auslassungen erkennen würden, würden wir schließlich die Größe von Red Hat erreichen [1].

Harter Markt

Unser Denken war ungefähr wie folgt. Neue Unternehmen basieren nicht auf Lösungen von Oracle, daher gibt es eine Nische, in der es möglich ist, ein Unternehmen mit einer neuen Infrastruktur aufzubauen. Der Datenbankmarkt ist riesig. Wenn wir ein Projekt erstellen, das einen Teil des Marktes erobert, werden wir zu dem Schluss kommen, dass wir ein sehr erfolgreiches Unternehmen werden.

Leider betreten Sie nicht den Markt, an den Sie denken - Sie befinden sich auf dem Markt, auf den Ihre Benutzer Sie führen . Und unsere Benutzer hatten eine klare Sicht auf uns als Open-Source-Tool-Unternehmen, denn genau das tun wir. Was sich für uns als sehr traurig herausstellte, da der Open-Source-Tool-Markt einer der schlechtesten Märkte ist, in denen sich jemand befinden könnte. Tausende von Menschen nutzten RethinkDB, teilweise im Rahmen des Geschäfts, aber die meisten wollten für die lebenslange Nutzung weniger bezahlen als für eine Tasse Kaffee von Starbucks (das heißt, sie wollten überhaupt nichts bezahlen).

Dies lag nicht daran, dass das Produkt so gut war, dass die Leute nicht für Unterstützung bezahlen mussten, oder daran, dass Programmierer das Budget nicht kontrollierten oder dass der Kapitalismus zusammenbrach. Die Antwort sind die Grundlagen der Mikroökonomie. Programmierer lieben es, Entwicklungswerkzeuge zu entwickeln, oft kostenlos. Und obwohl eine große Nachfrage besteht, ist das Angebot weit voraus. Die Anzahl der Alternativen steigt und die Preise fallen auf Null.

Um herauszufinden, wie sich dies auf andere Unternehmen auswirkt, schauen Sie sich MongoDB (im Wert von ca. 1,6 Mrd. USD ~ 700 Mitarbeiter) und Docker (im Wert von ca. 1 Mrd. USD ~ 300 Mitarbeiter) an. Beide Unternehmen dominieren absolut ihre Märkte. Nach zwei allgemein anerkannten Regeln werden wachsende private Softwareunternehmen auf das Zehnfache des Jahreseinkommens geschätzt, und das Einkommen pro Mitarbeiter beträgt ungefähr 200.000 USD / Jahr. Dies bedeutet, dass der Jahresumsatz von MongoDB zwischen 140 und 160 Millionen US-Dollar und der Jahresumsatz von Docker zwischen 60 und 100 Millionen US-Dollar liegt.

Dies sieht ziemlich gut aus, bis wir uns die vorherrschenden B2B-Technologieunternehmen in Märkten ansehen, die keine Märkte für Entwicklungswerkzeuge sind. Unternehmen wie SalesForce, Palantir oder Box (die einem harten Wettbewerb ausgesetzt sind). Und plötzlich sehen MongoDB und Docker winzig aus.

Obwohl dies äußerst erfolgreiche Unternehmen sind. Wenn relativ etablierte Unternehmen mit Partnerschaften, Vertriebsinfrastruktur und Zugang zu beeindruckenden Konten vor Wachstumsherausforderungen stehen, was bedeutet dies für ein Startup, das sich in einer aufstrebenden Phase befindet?

Für uns bedeutete dies einen schwer erreichbaren Verkaufstrichter. Wenn in einem prosperierenden B2B-Markt ein Startup hundert Leads verarbeiten muss, um zehn Gelegenheiten zu erhalten, einen Verkauf zu erzielen, wird diese Zahl für ein Startup, das an Entwicklungstools arbeitet, mit 10 multipliziert. Sie haben Zugriff auf viele gute Perspektiven - viele Menschen laden Ihr Produkt herunter und interagieren mit Ihnen, aber Sie müssen die Plage der Leads durchbrechen, um dem einzigen Verkauf näher zu kommen.

Dieser Prozess hat die katastrophalen Folgen von Dominosteinen. Das Team ist demoralisiert, es wird schwierig, Investitionen anzuziehen und die besten Profis einzustellen. Dies wiederum begrenzt die eigenen Ressourcen, so dass es unmöglich wird, erheblich in ein Produkt oder einen Vertrieb zu investieren. Fahrdynamik ist für Start-ups eine Frage von Leben und Tod, und Verteilungsschwierigkeiten in den frühen Stadien führen Sie fast immer zum sicheren Tod.

Falsche Gebrauchskriterien

Nun, der Markt ist schlecht, aber andere Unternehmen, die an Entwicklungstools beteiligt sind, verkaufen immer noch in großen Mengen. Warum nicht RethinkDB?

Obwohl wir mit der Dynamik des Marktes nichts anfangen konnten (außer etwas anderes zu tun), lagen die Produktentscheidungen ganz bei uns. Wir wollten ein elegantes, zuverlässiges und schönes Produkt bauen und wurden daher für die folgenden Metriken optimiert.

• Richtigkeit. Wir haben sehr hohe Garantien gegeben und diese strikt eingehalten .
• Die Einfachheit der Schnittstelle. Wir haben die meisten Implementierungsschwierigkeiten übernommen, um das Leben der Entwickler nicht zu verkomplizieren.
• Einheitlichkeit. Wir haben alles von der Abfragesprache über die Client-Treiber, die Cluster-Konfiguration und die Dokumentation bis hin zum Werbetext auf dem Cover so einheitlich wie möglich gemacht.

Wenn es uns bekannt vorkommt, haben wir diese Eigenschaften aus der Arbeit genommen, schlimmer noch, es ist besser . Es stellte sich heraus, dass die Richtigkeit, Einfachheit der Benutzeroberfläche und die Reihenfolge für die meisten Benutzer die falschen Kriterien für die Nützlichkeit sind. Die meisten Benutzer wollten stattdessen diese drei Optionen:

• Aktualität. Sie wollten, dass das Produkt wirklich funktioniert, wenn sie es brauchen, nicht drei Jahre später.
• Greifbare Geschwindigkeit. Die Leute wollten, dass RethinkDB unter den Belastungen, die Benutzer tatsächlich gaben, schnell ist, und nicht nur unter den Angeboten, die der "Realität" nahe kommen. Zum Beispiel schreiben sie schnelle Skripte, um zu messen, wie viel es kostet, zehntausend Dokumente ohne Lesen einzufügen. MongoDB hat diese Lasten hervorragend gemeistert, während wir in einem bereits verlorenen Markttrainingskampf gekämpft haben.
• Anwendungsfälle. Wir wollten ein gutes Datenbanksystem erstellen, aber Benutzer wollten einen guten Weg, um X zu erstellen (zum Beispiel einen guten Weg, um JSON-Dokumente aus Hapi zu speichern, einen guten Weg, um Protokolle zu speichern und zu analysieren, einen guten Weg, um Berichte zu erstellen usw.).

Dies bedeutet nicht, dass wir nicht versucht haben, schnell zu starten, RethinkDB schnell zu machen und ein Ökosystem darum herum aufzubauen, um nützliche Arbeit zu vereinfachen. Wir haben es geschafft. Richtige, einfache und konsistente Software ist jedoch zeitaufwändig. Dies führte dazu, dass wir drei Jahre hinter dem Markt zurückblieben.

Als wir der Meinung waren, dass RethinkDB zufriedenstellend ist, waren wir zuversichtlich genug, die Verwendung in der Produktion zu empfehlen. Fast alle fragten: „Wie unterscheidet sich RethinkDB von MongoDB?“. Wir haben hart gearbeitet, um zu erklären, warum Korrektheit, Einfachheit und Systemizität / Kompatibilität so wichtig sind, aber letztendlich waren diese Faktoren keine Nützlichkeitskriterien, die für die meisten Benutzer von Bedeutung waren.

Um ehrlich zu sein, tut es weh. Es tut sehr weh. Dies war für uns unverständlich, warum Menschen ein System gewählt haben, das kaum das tut, was es tun sollte (Daten speichern), den Kernel blockiert, durch Fehler verstreut ist, als ein Knoten fungiert, der beim Segmentieren nicht mehr funktioniert, trotz eines kaum funktionierenden Segmentierungssystems Die Tatsache, dass dies eines der Hauptmerkmale des Produkts ist, garantiert keinen korrekten Betrieb und wirft ein Durcheinander von Schnittstellen auf, bei denen es keine systematische oder einheitliche Sicht gibt.

Jedes Mal, wenn MongoDB eine Veröffentlichung herausbrachte und die Leute ihnen zu den Verbesserungen gratulierten, fühlte ich mich empört. Sie sagten, sie würden die BKL reparieren, aber tatsächlich reduzierten sie den Detaillierungsgrad von der Datenbank auf die Sammlung. Sie fügten weitere Operationen hinzu, aber anstatt einer modularen Schnittstelle, die mit dem System kombiniert wurde, haben sie einfach einmalige Befehle vermasselt. Sie hätten eine bessere Segmentierung, aber es war offensichtlich, dass sie nicht einmal elementare Garantien für die Datenkonsistenz wollten oder konnten.

Aber im Laufe der Zeit lernte ich die Weisheit der Menge zu schätzen. MongoDB verwandelte gewöhnliche Entwickler in Helden, wenn die Leute es brauchten , nicht Jahre später. Dies machte das Data Warehouse schnell und ermöglichte es den Mitarbeitern, Produkte schnell zu liefern. Und im Laufe der Zeit ist MongoDB gewachsen. Nacheinander haben sie Architekturprobleme behoben, und jetzt ist es ein großartiges Produkt. Er mag nicht so gut aussehen, wie wir es gerne hätten, aber er macht seinen Job und macht es gut.

Als Mitte 2014 klar wurde, dass wir nicht mithalten konnten, haben wir hart daran gearbeitet, uns von MongoDB zu unterscheiden. Wir haben eine sehr elegante Möglichkeit gefunden, Echtzeitbenachrichtigungen hinzuzufügen, in der Hoffnung, dass Entwickler auf diese Weise eine Generation von Anwendungen erstellen können, die sie zuvor nicht ausführen konnten. Das war aber nicht genug. Unerwartet für uns selbst erwiesen wir uns als Konkurrenten von Meteor und Firebase, Unternehmen, die sich der Lösung dringender Probleme widmeten, über die erst in einigen Jahren diskutiert wird. Und wieder waren wir drei Jahre hinter dem Markt, wieder stellten wir fest, dass wir nicht konkurrieren konnten.

Was ist mit der Cloud?

Mehrere Leute schlugen vor, dass wir einen Cloud-Service erstellen müssten. Wir hatten tatsächlich ein solches Projekt in der Entwicklung, daher ist dies ein interessantes Thema, das ich gerne behandeln möchte.

Das offensichtliche Problem bei der Entwicklung eines Cloud-Dienstes durch ein kleines Unternehmen besteht darin, dass es einen allgemeinen Fehlermodus hat - die Defokussierung. Es ist schwierig, einen mandantenfähigen Cloud-Service zu entwickeln, zu verteilen und zu betreiben. All dies erfordert außergewöhnliche Erfahrung und Ressourcen. Wenn Sie diesen Pfad wirklich betreten, werden Sie möglicherweise zwei Startups gleichzeitig verwalten. Aber wir waren mit der Bedrohung der Existenz konfrontiert, und unsere Handlungsoptionen gingen schnell zur Neige, sodass wir dieser Idee die Chance gaben, zu schießen. Nehmen wir für den Moment an, wir könnten diese Idee durchsetzen.

Unsere Argumentation war wie folgt. Ein Datenbankvorschlag kann eines von drei Dingen bedeuten: Managed Hosting, eine Datenbank als Service (DBaaS) oder eine erweiterte Plattform als Service (PaaS). Kehren wir zu der Marketinganalyse zurück, die auf dem Knie geschrieben wurde, wo wir den Parameter 200.000 USD / Mitarbeiter für den Jahresumsatz verwendet haben, dieselbe Regel , die wir zuvor verwendet haben:

	Verwaltetes Hosting	DBaaS	PaaS
Firma	Compose.io, mLab	Faunadb	Analysieren, Feuerbasis, Meteor
Mitarbeiter	~ 30	~ 30	~ 30
Einkommen	<10 Mio. USD	<10 Mio. USD	<10 Mio. USD

Diese Märkte sind klein, sogar kleiner als der Datenbankmarkt selbst. Vielleicht hättest du einen von ihnen dem anderen vorziehen sollen?

Managed Hosting besteht im Wesentlichen aus der Pflege einer AWS-Datenbank für Personen. Eine Alternative zur Verwendung dieser Dienste besteht darin, eine eigene AWS-Datenbank zu erstellen. Es ist ein Schmerz, aber es ist nicht so schwierig. Daher gibt es eine strenge Einschränkung bei der Bewertung von verwalteten Hosting-Diensten. Angesichts der Tatsache, dass Compose.io und mLab MongoDB anbieten, das eine Größenordnung mehr Kunden als RethinkDB hat, gingen wir davon aus, dass das Angebot von Managed Hosting keine großen Auswirkungen haben würde.

Eine Datenbank als Dienst ist eine komplexere Version des verwalteten Hostings. Beispielsweise trennt ein DBaaS-Dienst die Hostverwaltung vollständig vom Benutzer. Sie stellen nur Anfragen und das System verarbeitet sie. Sie wissen einfach nichts darüber, wie viele Knoten unter der Haube laufen. Dieses Geschäft ist nicht sehr einfach: Zum einen, weil DBaaS-Unternehmen mit Giganten (wie DynamoDB und DocumentDB) konkurrieren müssen, und zum anderen, weil Kunden nicht dazu neigen, das Datenmanagement vollständig an Startups zu übertragen, während es so viele andere Optionen und Alternativen gibt ( Kennen Sie jemanden, der DBaaS-Dienste von Anfang an nutzt?) Der Vorschlag für DBaaS bleibt also zurück.

Die letzte Option war die Entwicklung einer fortschrittlichen Plattform als Service. Wir dachten, es sei ein vielversprechender Bereich, weil wir einen großen technischen Vorteil darin hatten. Firebase und Meteor mussten eine Echtzeit-Anwendungslogik auf MongoDB aufbauen, was die Echtzeit-Abfragefunktionen und die Leistung auf der richtigen Ebene erheblich einschränkt. Auf der anderen Seite könnten wir den Stapel vollständig steuern und so erhebliche Vorteile bieten, die Firebase und Meteor nicht zur Verfügung standen.

Aus diesem Grund haben wir Horizon entwickelt und mit der Arbeit an der Horizon Cloud begonnen, mit der Benutzer die Möglichkeit haben, RethinkDB / Horizon-Anwendungen bereitzustellen und zu skalieren. Die Entwicklung von drei großen Projekten (RethinkDB, Horizon und Horizon Cloud) mit einem sehr kleinen Team hat uns schließlich überholt, und wir konnten immer noch keinen Cloud-Service veröffentlichen, bevor uns das Geld ausgegangen war. Respekt jedoch gegenüber dem Entwicklungsteam. Sie standen sich sehr, sehr nahe.

Meta-Fragen

Es gibt eine andere Ebene der Analyse der Grundursachen, auf die wir hinweisen können. Warum haben wir einen schlechten Markt gewählt und das Produkt nach den falschen Maßstäben optimiert?

Als ich ein Kind war, wollte ich mein eigenes Radio machen. Ich machte eine Schachtel Sperrholz, warf Metallreste von innen und verband die Schachtel mit dem Netzkabel. Ich hatte zu Hause Bücher über Elektronik, aber es schien mir, dass ich sie nicht brauchte. Ich hatte den unerschütterlichen Glauben, dass ich es selbst tun könnte. Am Ende baute ich einen funktionierenden Empfänger, aber es dauerte mehrere Jahre, bis ich endlich begriff, dass ich die Grundlagen der Elektronik lernen musste.

Das frühe RethinkDB war ein bisschen so. Wir hatten keine Intuition für Produkte und Märkte, daher waren wir einfach von der Idee getrieben, ein Unternehmen aufzubauen, und verstanden nicht wirklich, was wir taten. Darüber hinaus hatten wir eine unglaublich optimistische Einstellung . So wie Ärzte wissen, dass Geschenke von Pharmaunternehmen einen Sucht-Effekt auf andere Ärzte haben, aber sie glauben immer noch, dass sie von diesem Effekt nicht betroffen sind, dachten wir, wir hätten keine Wirtschaftsgesetze und eine mathematische Komponente der Geschäftstätigkeit. Und natürlich hat uns die Mathematik am Ende umgehauen.

Könnten wir etwas tun, um diese Fehler zu vermeiden? Nicht mehr als ich als Kind mit diesem Radio machen konnte. Wir haben nicht erkannt, dass wir inkompetent sind, und es hat Jahre gedauert, bis diese Inkompetenz bewusst wurde.

Mehrere Personen stellten fest, dass wir unsere Situation verbessern könnten, wenn wir ein erfahrenes Team aufbauen würden, das bereit ist, in den Markt einzutreten. Dies ist zu 100% wahr, aber die Zeit für unsere persönliche Entwicklung stimmte nicht mit den Bedürfnissen des Unternehmens überein. Anfangs wussten wir nicht, dass wir Expertenwissen und Erfahrung für den Markteintritt benötigen, deshalb haben wir uns nicht bemüht, dies in die notwendige Liste der Dinge aufzunehmen, um ein Team zu bilden. Als wir eine Denkweise entwickelten, die gut mit der Realität übereinstimmte, befanden wir uns in einem harten Markt voller würdiger Wettbewerber und eines Produkts, das drei Jahre zurückblieb. Bis dahin konnte uns selbst das beste marktfreundliche Team der Welt nicht retten.

Auf Wiedersehen Gedanken

Viele Menschen sind empört über den Markt für Entwicklertools. Entwickler möchten gerne Tools für Entwickler erstellen, daher möchten sie wirklich, dass Unternehmen, die Tools für Entwickler erstellen, florieren.

Ich möchte diesen Markt überhaupt nicht auslassen - teils, weil ich nicht auf der Grundlage einer Erfahrung verallgemeinern möchte, teils, weil ich nicht sagen möchte, dass dies unmöglich ist, und teils, weil es einige Ausnahmen gibt. GitHub, MongoDB und Docker haben beeindruckende Unternehmen geschaffen. GitLab und Unity scheinen es ebenfalls gut zu machen.

Wenn Sie wirklich beabsichtigen, eine Werkzeugentwicklungsfirma zu gründen, gehen Sie vorsichtig vor. Der Markt ist voller guter Alternativen. Die Erwartungen der Benutzer sind hoch und die Preise niedrig. Überlegen Sie genau, welchen Preis Sie dem Kunden anbieten. Denken Sie daran - der Wunsch, dass die Welt so ist, Sie wollen es, macht es nicht so.

2009 sprachen wir beim YCombinator-Demo-Tag über die ursprüngliche RethinkDB-Idee (wir hatten noch keine Software) eines Investorenpublikums. Wir haben den Folienbericht mit drei wichtigen Punkten abgeschlossen. "Wenn Sie sich nur an drei Dinge über RethinkDB erinnern können", sagten wir, "erinnern Sie sich an diese." Es hat funktioniert. Die Leute erinnerten sich an nichts aus der Rede, aber sie erinnerten sich am Ende an drei Punkte.

Ich werde mit drei wichtigen Punkten enden, an die es sich zu erinnern lohnt. Wenn Sie sich an diesen Artikel erinnern sollten, sollten Sie sich daran erinnern:

• Wählen Sie einen großen Markt, aber für bestimmte Benutzer.
• Lernen Sie, die Talente zu erkennen, die Ihnen fehlen, und pflügen Sie dann, um sie ins Team zu holen.
• Lesen Sie unbedingt The Economist . Es wird dich schneller besser machen.

[1] Lies nicht zu viele dieser Zahlen. Ich gab eine sehr grobe Schätzung ab, musste aber dennoch eine allgemeine Vorstellung von den Kosten dieser Fehler geben.

[2] , , , , , , .