RethinkDB：​​閉鎖した理由

記事の翻訳は、著者の許可を得て公開されました。

RethinkDBがシャットダウンすることを発表したとき、私は死後の批判を書くことを約束しました。 私は経験を再考するのに少し時間をかけました、そして今、私はそれを明確に述べることができます。

HNディスカッションスレッドで、人々はRethinkDBが失敗した多くの理由を説明しました。人間の性質の不可解な倒錯、MongoDBマーケティング担当者のunningな陰謀、市場に参入する準備ができた経験豊富なチームの構築の失敗など、64ビットfloatより大きな数値型のサポートの欠如で終わりました。 提案された失敗の理由のリストに関するコメントを要約しました。

それらのいくつかはいくらかの真実を持っていますが、それらは原因よりも可能性が高い症状です。 たとえば、金銭的利益を得る方法を学んでいないという声明は表面的なものです。 この声明は、成功しなかった理由を明らかにするものではありません。

振り返ってみると、2つのことが間違っていたと思います。厳しい市場を選択し、ユーザーにとっての誤った有用性の基準に従って製品を最適化しました。 これらの各エラーにより、RethinkDBの値が1桁または2桁減少した可能性があります。 したがって、これら2つのことのいずれかを正しく行うと、RethinkDBはMongoDBのサイズに達し、両方の省略を認識した場合、最終的にはRed Hat [1]のサイズに達します。

ハードマーケット

私たちの考えはおよそ次のとおりでした。 新しい企業はオラクルのソリューションに基づいて構築されていないため、新しいインフラストラクチャを備えた企業を構築できるニッチがあります。 データベース市場は巨大です。 市場の一部を取り込むプロジェクトを作成すると、非常に成功した会社になるという結論に達します。

残念ながら、あなたはあなたが考えている市場に参入していません-あなたはあなたのユーザーがあなたを連れて行く市場にいます 。 そして、私たちのユーザーは、オープンソースツール会社としての私たちの明確な見解を持っていました。 オープンソースツール市場は誰もが見つけることのできる最悪の市場の 1つであるため、私たちにとって非常に悲しいことになりました。 何千人もの人々がRethinkDBを使用しましたが、一部はビジネスのコンテキストでしたが、ほとんどの人はスターバックスのマグカップよりも生涯使用したほうが安いことを望んでいました（つまり、何も支払いたくありませんでした）。

これは、製品が非常に優れていて人々がサポートにお金を払う必要がなかったからでも、プログラマーが予算をコントロールしなかったからでも、資本主義の崩壊のためでもありませんでした。 答えはミクロ経済学の基本です。 プログラマは、多くの場合無料で開発ツールを開発するのが大好きです。 そして、大きな需要がありますが、オファーはそれよりもはるかに先です。 選択肢の数が増え、価格がゼロになります。

これが他の企業にどのように影響するかを調べるには、MongoDB（約16億ドルから700人の従業員に相当）およびDocker（約10億ドルから300人の従業員に相当）を見てください。 両社は絶対に市場を支配しています。 一般に受け入れられている2つのルールによると、成長中の民間ソフトウェア会社は年間収入の10倍と推定され、従業員1人あたりの収入は約20万ドル/年です。 つまり、MongoDBの年間収益は約140〜1億6,000万ドルであり、Dockerの年間収益は約60〜1億ドルです。

開発ツール市場ではない市場で普及しているB2Bテクノロジー企業を見るまで、これはかなり良いように見えます。 SalesForce、Parantir、Boxなどの企業（厳しい競争に直面しています）。 そして、突然、MongoDBとDockerは小さく見え始めます。

これらは非常に成功した企業ですが。 パートナーシップ、流通インフラ、印象的なアカウントへのアクセスを備えた比較的確立された企業が成長の課題に直面した場合、これは発芽段階にあるスタートアップにとって何を意味しますか？

私たちにとって、これは手の届きにくい販売目標到達プロセスを意味していました。 繁栄するB2B市場で、スタートアップが10の機会を獲得し、1つの販売を得るために100のリードを処理する必要がある場合、開発ツールで作業しているスタートアップの場合、この数は10倍になります。多くの人々が製品をダウンロードして対話しますしかし、あなたは唯一の販売に近づくためにリードのペストを突破する必要があります。

このプロセスは、ドミノの悲惨な結果をもたらします。 チームは意気消沈し、投資を引き付け、最高のプロを雇うことが難しくなります。 また、これにより、独自のリソースが制限されるため、製品や流通に大幅に投資することができなくなります。 運転のダイナミクスは、新興企業にとって生と死の問題であり、初期段階での流通の困難は、ほとんどの場合、特定の死に陥ります。

間違ったユーティリティ基準

まあ、市場は悪いですが、開発ツールに関与する他の企業はまだ大量に販売しています。 RethinkDBを選ばない理由

市場のダイナミクスについては何もできませんでしたが（何か他のことをする以外）、製品の決定は完全に私たちに任されていました。 エレガントで信頼性の高い美しい製品を作りたかったので、次の指標に最適化されました。

• 正確さ。 私たちは非常に高い保証を与え、それらを厳守 しました。
• インターフェイスのシンプルさ。 開発者の生活を複雑にしないために、実装のほとんどの困難を引き受けました。
• 均一性。 クエリ言語、クライアントドライバー、クラスター構成、ドキュメントから、表紙の広告テキストまで、可能な限り統一しました。

おなじみの場合は、これらの品質を仕事から取りましたが、 悪いほど良いです。 インターフェースの正確性、シンプルさ、およびシーケンスが、ほとんどのユーザーにとって有用な誤った基準であることが判明しました。 ほとんどのユーザーは、代わりに次の3つのオプションが必要でした。

• 適時。 彼らは、3年後ではなく、必要なときに製品が本当に機能することを望んでいました。
• タンジブル速度。 人々は、RethinkDBが、「現実」に近いオファリングの下だけでなく、ユーザーが実際に与えた負荷の下で高速であることを望んでいました。 たとえば、彼らは読み上げずに1万件のドキュメントを挿入するのにどれだけの時間がかかるかを測定するクイックスクリプトを作成します。 MongoDBはこれらの負荷を見事にマスターし、すでに失われた市場トレーニングの戦いで戦いました。
• ユースケース。 良いデータベースシステムを作成するつもりでしたが、ユーザーはXを作成する良い方法を望んでいました（たとえば、hapiからJSONドキュメントを保存する良い方法、ログを保存して分析する良い方法、レポートを作成する良い方法など）。

これは、高速で実行し、RethinkDBを高速化し、その周りにエコシステムを構築して有用な作業を簡単にしようとしたわけではありません。 やった しかし、正確でシンプルで一貫性のあるソフトウェアには時間がかかります。 これにより、市場から3年遅れました。

RethinkDBが満足できると感じるまでに、本番環境で使用することをお勧めする自信がありました。ほとんどの人が「RethinkDBとMongoDBの違い」と尋ねました。 正確性、シンプルさ、体系性/互換性が重要である理由を説明するために一生懸命努力しましたが、最終的に、これらの要素はほとんどのユーザーにとって重要な有用性の基準ではありませんでした。

正直なところ、痛い。 本当に痛いです。 人々がやるべきことをほとんど行わない（データを保存する）、カーネルをブロックする、エラーによって散らばる、セグメント化時に動作を停止する1つのノードとして機能するシステムを選択した理由は理解できませんでしたが、セグメンテーションシステムはほとんど機能していませんこれが製品の重要な機能の1つであるという事実は、正常な動作を保証するものではなく、体系性やビジョンの統一性のないインターフェースのミッシュマッシュを放り出します。

MongoDBがリリースを発表し、人々がそれらの改善を祝福するたびに、私はinりの急増を感じました。 彼らは、BKLを修正すると言いましたが、実際には、データベースからコレクションまで詳細レベルを下げました。 彼らはより多くの操作を追加しましたが、システムと組み合わされたモジュラーインターフェイスの代わりに、1回限りのコマンドを台無しにしました。 彼らはより良いセグメンテーションを持っているでしょうが、彼らがデータの一貫性について基本的な保証を望んでいないか、与えることさえできないことは明らかでした。

しかし、時間の経過とともに、私は群衆の知恵に感謝することを学びました。 MongoDBは、数年後ではなく、一般の開発者が必要なときにヒーローに変えました。 これにより、データウェアハウスが高速になり、人々が製品を迅速に提供できるようになりました。 そして、時間の経過とともに、MongoDBは成長しました。 ひとつひとつ、彼らはアーキテクチャの問題を修正し、今では素晴らしい製品です。 彼は私たちが望むほどハンサムではないかもしれませんが、彼は仕事をして、それをうまくやっています。

2014年半ばに競争できないことが明らかになったとき、MongoDBとは異なるものになるように懸命に取り組みました。 開発者が以前はできなかった世代のアプリケーションを作成できるように、 リアルタイム通知を追加する非常にエレガントな方法を見つけました。 しかし、それだけでは十分ではありませんでした。 思いがけないことに、私たちは、数年も議論されない差し迫った問題の解決に専念しているMeteorおよびFirebaseのライバルであることが判明しました。 そして再び、私たちは市場から3年遅れていました;再び、私たちは自分たちが競争できないことを発見しました。

クラウドはどうですか？

何人かの人々は、クラウドサービスを作成する必要があることを提案しました。 私たちは実際にそのようなプロジェクトを開発中でしたので、これは私がカバーしたい興味深いトピックです。

クラウドサービスを開発している小さな会社の明らかな問題は、一般的なフェイルモード-デフォーカスがあることです。 マルチテナントクラウドサービスの開発、配布、および維持は困難です。 これにはすべて、並外れた経験とリソースが必要です。したがって、このパスを本当に入力すると、2つのスタートアップを一度に管理できることに気付くかもしれません。 しかし、私たちは存在の脅威に直面しており、行動の選択肢がすぐになくなっていたので、このアイデアに射撃の機会を与えました。 とりあえず、このアイデアを推し進めることができるとしましょう。

理由は次のとおりです。 データベースの提案は、管理されたホスティング、サービスとしてのデータベース（DBaaS）、またはサービスとしての高度なプラットフォーム（PaaS）の3つのうちの1つを意味します。 膝の上に書かれたマーケティング分析に戻りましょう。ここでは、以前に使用したのと同じルールで、年間収益で20万ドル/従業員のパラメーターを使用しました。

	マネージドホスティング	DBaaS	PaaS
会社	Compose.io、mLab	動物相	解析、Firebase、Meteor
従業員	〜30	〜30	〜30
収入	<$ 10M	<$ 10M	<$ 10M

これらの市場は小さく、データベース市場自体よりも小さくなっています。 たぶん、あなたはそれらのうちの1つを他のものより好むべきでしたか？

マネージドホスティングは基本的に、人々のためにAWSデータベースを維持することで構成されます。 これらのサービスを使用する代わりに、独自のAWSデータベースを作成することもできます。 それは痛みですが、 それほど難しくありません。 したがって、マネージドホスティングサービスの評価方法には厳しい制限があります。 Compose.ioとmLabが、RethinkDBよりも桁違いに多くのクライアントを持つMongoDBを提供するという事実を考えると、マネージドホスティングの提供はあまり効果がないと想定しました。

サービスとしてのデータベースは、マネージドホスティングのより複雑なバージョンです。たとえば、DBaaSサービスは、ホスト管理とユーザーを完全に分離します。 リクエストを行うだけで、システムはそれらを処理します。 ボンネットの下で実行されるノードの数については何も知りません。 このビジネスは簡単ではありません：DBaaS企業が巨大企業（DynamoDBやDocumentDBなど）と競争する必要があるため、また、クライアントがデータ管理をスタートアップに完全に移行する傾向がないため、他にも多くのオプションや選択肢があります（スタートアップのDBaaSサービスを使用している人を知っていますか？）だから、DBaaSの提案は残されています。

最後のオプションは、高度なプラットフォームをサービスとして開発することでした。 技術的に大きな利点があるため、有望なエリアだと思いました。 FirebaseとMeteorは、MongoDBの上にリアルタイムアプリケーションロジックを構築する必要がありました。これにより、適切なレベルでのリアルタイムクエリ機能とパフォーマンスが大幅に制限されます。 一方、スタックを完全に制御できるため、FirebaseとMeteorにはない大きなメリットを提供できます。

そのため、 Horizo​​nを開発し、Horizo​​n Cloudでの作業を開始しました。これにより、ユーザーはRethinkDB / Horizo​​nアプリケーションを展開およびスケーリングできます。 非常に小さなチームによる3つの大規模プロジェクト（RethinkDB、Horizo​​n、およびHorizo​​n Cloud）の開発がついに私たちを追い越し、資金が尽きるまでクラウドサービスをリリースできませんでした。 ただし、開発チームを尊重します。 彼らは非常に非常に近かった。

メタ質問

指摘できる根本原因の分析には、別のレベルがあります。 なぜ悪い市場を選択し、間違ったメトリックに従って製品を最適化したのですか？

子供の頃、自分のラジオを作りたかった。 私は合板の箱を作り、内側から金属の破片をいくつか投げ、箱を電源コードに接続しました。 私は自宅で電子機器に関する本を持っていましたが、私はそれらを必要としないように思えました。私は自分でそれをやれるという揺るぎない信仰を持っていました。 最終的には実用的な受信機を構築しましたが、エレクトロニクスの基礎を学ぶ必要があることを最終的に理解するには数年かかりました。

初期のRethinkDBはそのようなものでした。 私たちは製品や市場について直観を持っていなかったので、私たちは単に会社を設立するというアイデアに駆り立てられていました。 さらに、私たちは非常に楽観的な態度を取りました 。 医師が製薬会社からの贈り物が他の医師に中毒効果があることを知っているように、彼らはまだ彼らがこの効果の影響を受けないと信じているので、私たちには経済法とビジネスを行う数学的な要素はないと考えました。 そして、もちろん、結局、数学は私たちをノックダウンしました。

これらの間違いを避けるために何かできるでしょうか？ そのラジオで子供の頃にできる以上のことはありません。 私たちは自分が無能であることに気づきませんでした。そして、この無能さが意識的になるには何年もかかりました。

何人かの人々は、市場に参入する準備ができている経験豊富なチームを構築すれば状況を改善できると指摘しました。 これは100％真実ですが、私たちの個人的な成長の時間は会社のニーズに同意しませんでした。 当初は、市場参入に専門知識と経験が必要であることを知りませんでしたので、チームを形成するために必要なもののリストにこれを含めるように努力しませんでした。 現実とよく一致するタイプの思考を開発する頃には、価値のある競合他社と3年遅れの製品に満ちた厳しい市場に座り込んでいた。 それまでに、世界で最高の市場に優しいチームでさえ、私たちを救うことができませんでした。

さようなら

多くの人々は、開発者ツールの市場について激怒しています。 開発者は開発者向けのツールを作成することを好むため、開発者向けのツールを作成する企業が繁栄することを本当に望んでいます。

ひとつの経験に基づいて一般化したくないので、そして「することは不可能です」と言いたくないので、そしていくつかの例外があるので、この市場をまったく省略したくないでしょう。 GitHub、MongoDB、Dockerは印象的な企業を生み出しました。 GitLabとUnityもうまくいっているようです。

本当にツール開発会社を設立するつもりであれば、注意して進めてください。 市場には優れた選択肢がたくさんあります。 ユーザーの期待は高く、価格は低いです。 顧客に提供する価格を慎重に検討してください。 覚えておいてください-世界がそうであることを望む、あなたはそれを望んで、それをそのようにしない。

2009年に、YCombinatorデモ日での投資家の聴衆の元のRethinkDBのアイデア（まだソフトウェアを持っていませんでした）について話しました。 スライドレポートは3つの重要なポイントで終了しました。 「RethinkDBについて3つのことしか思い出せない場合は、これらを覚えておいてください」と言いました。 うまくいきました。 人々はスピーチから何も覚えていませんでしたが、最後に3つのポイントを覚えていました。

最後に、覚えておくべき3つの重要なポイントを説明します。 この記事で覚えておく価値があるものがある場合は、これを覚えておく価値があります。

• 大規模な市場を選択しますが、特定のユーザーを対象にします。
• 不足している才能を認識し、チームでそれらを獲得するために耕します。
• エコノミストを必ずお読みください。 それはあなたをより速くより良くします。

[1]これらの数字を読みすぎないでください。 私は非常に大まかな見積もりを出しましたが、それでもこれらのエラーのコストについて一般的な考えを与えなければなりませんでした。

[2]ちなみに、優れたビジネスの直観力を持たずにビジネスに有能な人を認識することは、エンジニアリングの直観力を持たずに優れたエンジニアを認識することと同じくらい困難です。