RethinkDB: pourquoi nous avons fermé

La traduction de l'article a été publiée avec la permission de l'auteur.

Lorsque nous avons annoncé la fermeture de RethinkDB, j'ai promis d'écrire une critique posthume. J'ai pris un peu de temps pour repenser l'expérience, et maintenant je peux le dire clairement.

Dans le fil de discussion HN, les gens ont décrit de nombreuses raisons pour lesquelles RethinkDB a échoué, allant de la perversion inexplicable de la nature humaine, des machinations astucieuses des spécialistes du marketing MongoDB et de l'incapacité à créer une équipe expérimentée prête à entrer sur le marché, se terminant par le manque de support pour les types numériques supérieurs à 64 bits. J'ai résumé les commentaires sur la liste des raisons de l'échec qui ont été suggérées.

Certains d'entre eux ont une certaine vérité, mais ce sont des symptômes plus probables que des causes. Par exemple, l'affirmation selon laquelle nous n'avons pas appris comment obtenir un gain financier est superficielle. Cette déclaration n'éclaire pas les raisons pour lesquelles nous n'avons pas réussi.

Avec le recul, je conclus que deux choses ont mal tourné - nous avons choisi un marché difficile et optimisé le produit selon les mauvais critères d'utilité pour l'utilisateur. Chacune de ces erreurs a probablement réduit la valeur de RethinkDB d'un ou deux ordres de grandeur. Par conséquent, si nous avions fait l'une de ces deux choses correctement, RethinkDB aurait atteint la taille de MongoDB, et si nous avions réalisé les deux omissions, nous aurions finalement atteint la taille de Red Hat [1].

Marché dur

Notre réflexion était approximativement la suivante. Les nouvelles entreprises ne sont pas construites sur la base des solutions d'Oracle, il existe donc un créneau dans lequel il est possible de créer une entreprise avec une nouvelle infrastructure. Le marché des bases de données est énorme. Si nous créons un projet qui capturera une partie du marché, nous arriverons à la conclusion que nous deviendrons une entreprise très prospère.

Malheureusement, vous n'entrez pas sur le marché auquel vous pensez - vous êtes sur le marché où vos utilisateurs vous emmènent . Et nos utilisateurs avaient une vision claire de nous en tant qu'entreprise d'outils open source, car c'est ce que nous faisons. Ce qui s'est avéré très triste pour nous, car le marché des outils open source est l'un des pires marchés sur lesquels tout le monde puisse se retrouver. Des milliers de personnes ont utilisé RethinkDB, en partie dans le contexte de l'entreprise, mais la plupart voulaient payer moins pour une utilisation à vie que pour une tasse de café de Starbucks (c'est-à-dire qu'elles ne voulaient rien payer du tout).

Ce n'était pas parce que le produit était si bon que les gens n'avaient pas à payer pour le soutien, ou parce que les programmeurs ne contrôlaient pas le budget ou à cause de l'effondrement du capitalisme. La réponse est les bases de la microéconomie. Les programmeurs adorent développer des outils de développement, souvent gratuitement. Et bien qu'il y ait une forte demande, l'offre est loin devant. Le nombre d'alternatives augmente et les prix tombent à zéro.

Pour savoir comment cela affecte d'autres entreprises, regardez MongoDB (d'une valeur d'environ 1,6 milliard de dollars ~ 700 employés) et Docker (d'une valeur d'environ 1 milliard de dollars ~ 300 employés). Les deux sociétés dominent absolument leurs marchés. Selon deux règles généralement acceptées, les sociétés de logiciels privées en croissance sont estimées à dix fois le revenu annuel, et le revenu par employé est d'environ 200 000 $ / an. Ce qui signifie que les revenus annuels de MongoDB sont d'environ 140 à 160 millions de dollars, et les revenus annuels de Docker sont d'environ 60 à 100 millions de dollars.

Cela semble assez bon jusqu'à ce que nous examinions les entreprises technologiques B2B dominantes sur des marchés qui ne sont pas des marchés d'outils de développement. Des entreprises comme SalesForce, Palantir ou Box (qui font face à une forte concurrence). Et tout d'un coup, MongoDB et Docker commencent à paraître minuscules.

Bien que ce soient des entreprises extrêmement prospères. Si des entreprises relativement établies avec des partenariats, une infrastructure de distribution et un accès à des comptes impressionnants sont confrontées à des défis de croissance, qu'est-ce que cela signifie pour une startup qui est en train de germer?

Pour nous, cela signifiait un entonnoir de vente difficile à atteindre. Si dans un marché B2B prospère, une startup doit traiter cent leads pour obtenir dix opportunités, obtenir une vente, puis pour une startup travaillant sur des outils de développement, ce nombre est multiplié par 10. Vous avez accès à de nombreuses bonnes perspectives - de nombreuses personnes téléchargent votre produit et interagissent avec vous, mais vous devez briser le fléau des prospects pour vous rapprocher de la seule vente.

Ce processus a les conséquences désastreuses des dominos. L'équipe est démoralisée, il devient difficile d'attirer des investissements et d'embaucher les meilleurs pros. À son tour, cela limite ses propres ressources, il devient donc impossible d'investir de manière significative dans un produit ou une distribution. La dynamique de conduite est une question de vie ou de mort pour les start-ups, et les difficultés de distribution dans les premiers stades vous condamnent presque toujours à une mort certaine.

Mauvais critères d'utilité

Eh bien, le marché est mauvais, mais d'autres sociétés impliquées dans les outils de développement vendent toujours en gros volumes. Pourquoi ne pas repenserDB?

Bien que nous ne puissions rien faire avec la dynamique du marché (à part faire autre chose), les décisions sur les produits étaient entièrement à nous. Nous voulions créer un produit élégant, fiable et beau, nous avons donc été optimisés pour les mesures suivantes.

• Exactitude. Nous avons donné des garanties très élevées et les avons strictement respectées .
• La simplicité de l'interface. Nous avons assumé la plupart des difficultés d'implémentation afin de ne pas compliquer la vie des développeurs.
• Uniformité. Nous avons tout fait du langage de requête, des pilotes clients, de la configuration du cluster, de la documentation, au texte publicitaire sur la couverture aussi uniforme que possible.

Si cela vous semble familier, nous avons retiré ces qualités du travail; pire c'est mieux . Il s'est avéré que l'exactitude, la simplicité de l'interface et la séquence ne sont pas les bons critères d'utilité pour la plupart des utilisateurs. La plupart des utilisateurs souhaitaient plutôt ces trois options:

• Rapidité. Ils voulaient que le produit fonctionne vraiment quand ils en avaient besoin, pas trois ans plus tard.
• Vitesse tangible. Les gens voulaient que RethinkDB soit rapide sous les charges que les utilisateurs ont réellement données, et pas seulement sous les offres qui sont proches de la «réalité». Par exemple, ils écrivent des scripts rapides pour mesurer combien il faut pour insérer dix mille documents sans les lire. MongoDB a parfaitement maîtrisé ces charges pendant que nous nous battions dans une bataille de formation sur le marché déjà perdue.
• Cas d'utilisation. Nous avions l'intention de créer un bon système de base de données, mais les utilisateurs voulaient un bon moyen de créer X (par exemple, un bon moyen de sauvegarder des documents JSON à partir de hapi, un bon moyen de sauvegarder et d'analyser les journaux, un bon moyen de créer des rapports, etc.).

Cela ne signifie pas que nous n'avons pas essayé de démarrer rapidement, de rendre RethinkDB rapide et de construire un écosystème autour de lui pour faciliter le travail utile. Nous l'avons fait. Mais un logiciel correct, simple et cohérent prend du temps. Cela a causé notre retard de trois ans sur le marché.

Au moment où nous avons estimé que RethinkDB était satisfaisant, nous étions suffisamment confiants pour recommander de l'utiliser en production, presque tout le monde a demandé «en quoi RethinkDB est-il différent de MongoDB»? Nous avons travaillé dur pour expliquer pourquoi l'exactitude, la simplicité et la systémicité / compatibilité sont si importantes, mais au final, ces facteurs n'étaient pas des critères d'utilité qui importaient à la plupart des utilisateurs.

Pour être honnête, ça fait mal. Ça fait vraiment mal. C'était incompréhensible pour nous, pourquoi les gens ont choisi un système qui fait à peine ce qu'il devrait faire (stocker des données), bloque le noyau, est dispersé par des erreurs, fonctionne comme un nœud qui cesse de fonctionner lors de la segmentation, a un système de segmentation à peine fonctionnel, malgré Le fait que ce soit l'une des principales caractéristiques du produit ne garantit pas un fonctionnement correct et jette un fouillis d'interfaces dans lesquelles il n'y a pas de vision systématique ou uniforme.

Chaque fois que MongoDB a lancé une version et que les gens les ont félicités pour les améliorations, j'ai ressenti une vague d'indignation. Ils ont dit qu'ils répareraient le BKL, mais en fait ils ont abaissé le niveau de détail de la base de données à la collection. Ils ont ajouté plus d'opérations, mais au lieu d'une interface modulaire qui se combinait avec le système, ils ont simplement foiré des commandes uniques. Ils auraient une meilleure segmentation, mais il était évident qu'ils ne voulaient ou ne pouvaient même pas donner des garanties élémentaires sur la cohérence des données.

Mais au fil du temps, j'ai appris à apprécier la sagesse de la foule. MongoDB a transformé les développeurs ordinaires en héros lorsque les gens en avaient besoin , pas des années plus tard. Cela a rendu l'entrepôt de données rapide et a permis aux gens de livrer rapidement des produits. Et au fil du temps, MongoDB a grandi. Un par un, ils ont corrigé des problèmes d'architecture, et maintenant c'est un excellent produit. Il n'est peut-être pas aussi beau que nous le souhaiterions, mais il fait son travail et le fait bien.

Quand il est devenu clair à la mi-2014 que nous ne pouvions pas rivaliser, nous avons travaillé dur pour être différent de MongoDB. Nous avons trouvé un moyen très élégant d'ajouter des notifications en temps réel , en espérant que cela permettrait aux développeurs de créer une génération d'applications qu'ils ne pouvaient pas faire auparavant. Mais cela ne suffisait pas. De façon inattendue pour nous-mêmes, nous nous sommes avérés être des concurrents de Meteor et Firebase, des entreprises qui se sont consacrées à la résolution de problèmes urgents, qui ne seront même pas discutés avant plusieurs années. Et encore une fois, nous avions trois ans de retard sur le marché, encore une fois, nous avons constaté que nous n'étions pas en mesure de rivaliser.

Et le cloud?

Plusieurs personnes ont suggéré que nous devions créer un service cloud. Nous avions en fait un de ces projets en développement, c'est donc un sujet intéressant que je voudrais aborder.

Le problème évident avec une petite entreprise développant un service cloud est qu'elle a un mode de défaillance commun - défocalisation. Il est difficile de développer, de distribuer et d'exploiter un service cloud multi-locataire. Tout cela nécessite une expérience et des ressources extraordinaires, donc si vous entrez vraiment dans cette voie, vous pouvez constater que vous gérez deux startups à la fois. Mais nous étions confrontés à la menace de l'existence, et nos options d'action s'épuisaient rapidement, alors nous avons donné à cette idée une chance de tirer. Supposons pour le moment que nous puissions faire avancer cette idée.

Notre raisonnement était le suivant. Une proposition de base de données pourrait signifier l'une des trois choses suivantes: l'hébergement géré, une base de données en tant que service (DBaaS) ou une plate-forme avancée en tant que service (PaaS). Revenons à l'analyse marketing écrite à genoux, où nous avons utilisé le paramètre 200 000 $ / employé en revenus annuels, la même règle que nous avons utilisée précédemment:

	Hébergement géré	DBaaS	PaaS
Compagnie	Compose.io, mLab	Faunadb	Parse, Firebase, Meteor
Les employés	~ 30	~ 30	~ 30
Revenu	<10 M $	<10 M $	<10 M $

Ces marchés sont petits, voire plus petits que le marché des bases de données lui-même. Peut-être auriez-vous dû préférer l'un d'eux à l'autre?

L'hébergement géré consiste essentiellement à maintenir une base de données AWS pour les personnes. Une alternative à l'utilisation de ces services consiste à créer votre propre base de données AWS. C'est une douleur, mais ce n'est pas si difficile. Par conséquent, il existe une restriction sévère sur la façon d'évaluer les services d'hébergement gérés. Étant donné que Compose.io et mLab offrent MongoDB, qui a un ordre de grandeur plus de clients que RethinkDB, nous avons supposé que l'offre d'hébergement géré n'aurait pas beaucoup d'effet.

Une base de données en tant que service est une version plus complexe de l'hébergement géré, par exemple, un service DBaaS sépare complètement la gestion de l'hôte de l'utilisateur. Vous faites simplement des demandes et le système les traite. Vous ne savez tout simplement pas combien de nœuds fonctionnent sous le capot. Cette activité n'est pas très simple: en partie parce que les entreprises DBaaS doivent rivaliser avec des géants (tels que DynamoDB et DocumentDB) et en partie parce que les clients ne sont pas enclins à transférer complètement la gestion des données aux startups, alors qu'il existe de nombreuses autres options et alternatives ( Connaissez-vous quelqu'un qui utilise les services DBaaS à partir d'une startup?) Ainsi, la proposition pour DBaaS est laissée pour compte.

La dernière option était de développer une plate-forme avancée en tant que service. Nous pensions que c'était un domaine prometteur, car nous avions un énorme avantage technique. Firebase et Meteor ont dû créer une logique d'application en temps réel au-dessus de MongoDB, ce qui limite considérablement les capacités de requête en temps réel et les performances au bon niveau. D'un autre côté, nous pouvions contrôler la pile tout le long, afin de pouvoir offrir des avantages importants qui n'étaient pas disponibles pour Firebase et Meteor.

Par conséquent, nous avons développé Horizon et commencé à travailler sur Horizon Cloud, avec lequel les utilisateurs auraient la possibilité de déployer et de mettre à l'échelle des applications RethinkDB / Horizon. Le développement de trois grands projets (RethinkDB, Horizon et Horizon Cloud) avec une très petite équipe nous a finalement dépassés, et nous ne pouvions toujours pas publier un service cloud avant de manquer d'argent. Cependant, respect à l'équipe de développement. Ils étaient très, très proches.

Méta questions

Il existe un autre niveau d'analyse des causes profondes que nous pouvons signaler. Pourquoi avons-nous choisi un mauvais marché et optimisé le produit en fonction des mauvaises mesures?

Quand j'étais enfant, je voulais créer ma propre radio. J'ai fait une boîte de contreplaqué, jeté des débris métalliques de l'intérieur et connecté la boîte au cordon d'alimentation. J'avais des livres sur l'électronique à la maison, mais il me semblait que je n'en avais pas besoin, j'avais une foi inébranlable que je pouvais le faire moi-même. Au final, j'ai construit un récepteur fonctionnel, mais il m'a fallu plusieurs années pour finalement comprendre que je devais apprendre les bases de l'électronique.

Early RethinkDB était un peu comme ça. Nous n'avions aucune intuition pour les produits et les marchés, nous étions donc simplement motivés par l'idée de créer une entreprise, sans vraiment comprendre ce que nous faisions. De plus, nous avions une incroyable attitude optimiste . Tout comme les médecins savent que les cadeaux des sociétés pharmaceutiques ont un effet de dépendance sur les autres médecins, mais ils croient toujours qu'ils ne sont pas affectés par cet effet, nous avons donc pensé que nous n'avions pas de lois économiques et une composante mathématique pour faire des affaires. Et, bien sûr, à la fin, les mathématiques nous ont renversés.

Pouvons-nous faire quelque chose pour éviter ces erreurs? Pas plus que je ne pouvais faire enfant avec cette radio. Nous ne savions pas que nous étions incompétents, et il a fallu des années pour que cette incompétence devienne consciente.

Plusieurs personnes ont noté que nous pourrions améliorer notre situation si nous construisions une équipe expérimentée prête à entrer sur le marché. C'est vrai à 100%, mais le temps de notre développement personnel n'était pas en accord avec les besoins de l'entreprise. Au départ, nous ne savions pas que nous avions besoin de connaissances et d'expérience spécialisées pour entrer sur le marché, nous n'avons donc pas cherché à l'inclure dans la liste des éléments nécessaires pour former une équipe. Au moment où nous avons développé un type de pensée qui correspondait bien à la réalité, nous étions échoués dans un marché difficile plein de concurrents dignes et d'un produit avec trois ans de retard. D'ici là, même la meilleure équipe favorable au marché au monde ne pouvait pas nous sauver.

Pensées d'adieu

Beaucoup de gens sont indignés par le marché des outils de développement. Les développeurs aiment créer des outils pour les développeurs, ils veulent donc vraiment que les entreprises qui fabriquent des outils pour les développeurs prospèrent.

Je ne voudrais pas du tout omettre ce marché - en partie parce que je ne veux pas généraliser sur la base d'une expérience, et en partie parce que je n'aime pas dire "c'est impossible à faire" et en partie parce qu'il y a pas mal d'exceptions. GitHub, MongoDB et Docker ont créé des entreprises impressionnantes. GitLab et Unity semblent également bien fonctionner.

Si vous avez vraiment l'intention de créer une entreprise de développement d'outils, procédez avec prudence. Le marché regorge de bonnes alternatives. Les attentes des utilisateurs sont élevées et les prix bas. Considérez soigneusement le prix que vous offrez au client. Rappelez-vous - le désir que le monde soit comme ça, vous le voulez, ne le fait pas comme ça.

En 2009, nous avons parlé de l'idée originale de RethinkDB (nous n'avions pas encore de logiciel) d'un public d'investisseurs lors de la journée de démonstration de YCombinator. Nous avons terminé le rapport de diapositive avec trois points clés. "Si vous ne vous souvenez que de trois choses à propos de RethinkDB", nous avons dit, "souvenez-vous-en." Ça a marché. Les gens ne se souvenaient de rien du discours, mais ils se souvenaient de trois points à la fin.

Je terminerai par trois points clés qui méritent d'être rappelés. Si quelque chose mérite d'être rappelé dans cet article, il vaut la peine de le rappeler:

• Choisissez un grand marché, mais faites pour des utilisateurs spécifiques.
• Apprenez à reconnaître les talents qui vous manquent, puis labourez-les pour les intégrer dans l'équipe.
• Lisez The Economist sans faute. Cela vous rendra meilleur plus rapidement.

[1] Ne lisez pas trop de ces chiffres. J'ai donné une estimation très approximative, mais je devais quand même donner une idée générale du coût de ces erreurs.

[2] , , , , , , .