تم نشر ترجمة المقال بإذن من المؤلف.عندما أعلنا أن RethinkDB كان يغلق ، لقد وعدت بكتابة نقد بعد وفاته. لقد استغرقت بعض الوقت لإعادة التفكير في التجربة ، والآن يمكنني أن أذكرها بوضوح.
في
موضوع مناقشة HN ، وصف الأشخاص العديد من الأسباب التي أدت إلى فشل RethinkDB ، بدءً من الانحراف الذي لا يمكن تفسيره للطبيعة البشرية ، والمكائد الماكرة للمسوقين في MongoDB والفشل في إنشاء فريق من ذوي الخبرة جاهز للدخول إلى السوق ، مع عدم وجود دعم لأنواع رقمية أكبر من تعويم 64 بت. لقد لخصت التعليقات على
قائمة أسباب الفشل التي تم اقتراحها.
البعض منهم لديه بعض الحقيقة ، لكنها أعراض أكثر احتمالا من الأسباب. على سبيل المثال ، القول بأننا لم نتعلم كيفية الحصول على مكاسب مالية هو سطحي. هذا البيان لا ينير على أسباب
عدم نجاحنا.
إذا نظرنا إلى الوراء ، أستنتج أن هناك شيئان خاطئان - اخترنا سوقًا صعبًا وقمنا بتحسين المنتج وفقًا لمعايير الخطأ الخاطئة للمستخدم. كل من هذه الأخطاء ربما خفضت قيمة RethinkDB بمقدار واحد أو اثنين من أوامر الحجم. لذلك ، إذا قمنا بأحد هذين الأمرين بشكل صحيح ، فستصل RethinkDB إلى حجم MongoDB ، وإذا أدركنا كل من الإغفالات ، فسنصل في النهاية إلى حجم القبعة الحمراء [1].
سوق الصعب
كان تفكيرنا تقريبا على النحو التالي. الشركات الجديدة ليست مبنية
على أساس حلول من أوراكل ، لذلك هناك مكان يمكن من خلالها بناء شركة ذات بنية تحتية جديدة. سوق قاعدة البيانات ضخم. إذا أنشأنا مشروعًا يستحوذ على جزء من السوق ، فسنتوصل إلى استنتاج أننا سنصبح شركة ناجحة للغاية.
لسوء الحظ ، أنت لا تدخل السوق الذي تفكر فيه - أنت في السوق حيث
يأخذك مستخدميك . وكان لدى مستخدمينا رؤية واضحة لنا كشركة أدوات مفتوحة المصدر ، لأن هذا ما نقوم به. لقد أصبح هذا الأمر محزنًا للغاية بالنسبة لنا ، لأن سوق الأدوات مفتوحة المصدر هو أحد
أسوأ الأسواق التي يمكن لأي شخص أن يجد نفسه فيها. استخدم الآلاف من الناس RethinkDB ، جزئياً في سياق العمل ، لكن معظمهم أرادوا أن يدفعوا مقابل استخدامهم مدى الحياة مقابل استخدام فنجان قهوة من ستاربكس (أي أنهم لا يريدون دفع أي شيء على الإطلاق).
لم يكن هذا بسبب أن المنتج كان جيدًا لدرجة أنه لم يكن على الأشخاص الدفع مقابل الدعم ، أو لأن المبرمجين لم يتحكموا في الميزانية أو بسبب انهيار الرأسمالية. الجواب هو أساسيات الاقتصاد الجزئي. يحب المبرمجون تطوير أدوات التطوير ، غالبًا مجانًا. وعلى الرغم من وجود طلب كبير ، إلا أن العرض متقدم عليه. يرتفع عدد البدائل ،
وتنخفض الأسعار إلى الصفر.
لمعرفة كيف يؤثر ذلك على الشركات الأخرى ، انظر إلى MongoDB (تبلغ قيمتها حوالي 1.6 مليار دولار إلى 700 موظف) و Docker (تبلغ قيمتها حوالي مليار دولار إلى 300 موظف). كلا الشركتين تهيمن تماما أسواقها. وفقًا لقاعدتين مقبولتين عمومًا ، تقدر شركات البرمجيات الخاصة المتنامية بعشرة أضعاف الدخل السنوي ، ويبلغ دخل كل موظف حوالي 200 ألف دولار سنويًا. مما يعني أن إيرادات MongoDB السنوية تتراوح بين 140 و 160 مليون دولار ، وإيرادات دوكر السنوية حوالي 60 - 100 مليون دولار.
هذا يبدو جيدًا إلى حد ما حتى ننظر إلى شركات التكنولوجيا B2B السائدة في الأسواق التي
ليست أسواق أدوات تطوير. شركات مثل SalesForce أو Palantir أو Box (التي تواجه منافسة شديدة). وفجأة ، يبدأ MongoDB و Docker في الصغر.
على الرغم من أن هذه شركات ناجحة للغاية. إذا واجهت الشركات المنشأة نسبيًا ذات الشراكات والبنية التحتية للتوزيع والوصول إلى حسابات رائعة تحديات نمو ، فماذا يعني ذلك بالنسبة للشركات الناشئة التي تمر بمرحلة نمو؟
بالنسبة لنا ، كان هذا يعني تحويل مبيعات يصعب الوصول إليها. إذا كان في شركة B2B مزدهرة ، تحتاج شركة ناشئة إلى معالجة مائة عميل متوقع للحصول على عشر فرص ، والحصول على عملية بيع واحدة ، ثم لبدء التشغيل تعمل على أدوات التطوير ، يتم ضرب هذا الرقم في 10. يمكنك الوصول إلى العديد من الفرص الجيدة - كثير من الناس يقومون بتنزيل منتجك والتفاعل معك ، لكنك بحاجة لاختراق طاعون الخيوط لتقترب من البيع الوحيد.
هذه العملية لها عواقب وخيمة من الدومينو. الفريق معنويات ، يصبح من الصعب جذب الاستثمار وتوظيف أفضل المحترفين. وهذا بدوره يحد من موارده الخاصة ، لذلك يصبح من المستحيل الاستثمار بشكل كبير في منتج أو توزيع. ديناميات القيادة هي مسألة حياة أو موت بالنسبة للشركات الناشئة ، وصعوبات التوزيع في المراحل المبكرة تقضي دائمًا على الموت المؤكد.
معايير فائدة خاطئة
حسنًا ، السوق سيء ، لكن الشركات الأخرى المشاركة في أدوات التطوير لا تزال تبيع بكميات كبيرة. لماذا لا RethinkDB؟
على الرغم من أننا لم نتمكن من فعل أي شيء بديناميات السوق (بخلاف فعل شيء آخر) ، فإن قرارات المنتج كانت متروكة لنا تمامًا. لقد أردنا أن نبني منتجًا أنيقًا وموثوقًا وجميلًا ، لذلك تم تحسين المقاييس التالية.
- صحة. لقد قدمنا ضمانات عالية جدًا وامتثلت تمامًا لها.
- بساطة الواجهة. لقد واجهنا معظم صعوبات التنفيذ حتى لا نعقّد حياة المطورين.
- التوحيد. لقد فعلنا كل شيء من لغة الاستعلام ، وبرامج تشغيل العملاء ، وتكوين نظام المجموعة ، والوثائق ، إلى نص الإعلان على الغلاف بشكل موحد قدر الإمكان.
إذا بدا الأمر مألوفًا ، فقد أخذنا هذه الصفات من العمل ؛
والأسوأ أنها أفضل . اتضح أن صحة وبساطة الواجهة والتسلسل هي
معايير خاطئة
لفائدة معظم المستخدمين. أراد معظم المستخدمين هذه الخيارات الثلاثة بدلاً من ذلك:
- في الوقت المناسب. لقد أرادوا أن يعمل المنتج حقًا عندما يحتاجون إليه ، وليس بعد ثلاث سنوات.
- سرعة ملموسة. أراد الناس أن يكون RethinkDB سريعًا في ظل الأحمال التي قدمها المستخدمون بالفعل ، وليس فقط تحت العروض القريبة من "الواقع". على سبيل المثال ، يكتبون برامج نصية سريعة لقياس مقدار ما يتطلبه الأمر لإدراج عشرة آلاف مستند دون قراءة. لقد أتقنت MongoDB هذه الأحمال بشكل رائع أثناء قتالنا في معركة تدريب السوق المفقودة بالفعل.
- استخدام الحالات. لقد اعتزمنا إنشاء نظام قاعدة بيانات جيد ، لكن المستخدمين أرادوا طريقة جيدة لإنشاء X (على سبيل المثال ، طريقة جيدة لحفظ مستندات JSON من hapi ، وهي طريقة جيدة لحفظ السجلات وتحليلها ، وطريقة جيدة لإنشاء التقارير ، وما إلى ذلك).
هذا لا يعني أننا لم نحاول البدء بسرعة ، وجعل RethinkDB سريعًا وبناء نظام بيئي حوله لتسهيل العمل المفيد. لقد فعلنا ذلك. لكن البرامج الصحيحة والبسيطة والمتسقة تستغرق وقتًا طويلاً. هذا سبب تأخرنا وراء السوق لمدة ثلاث سنوات.
بحلول الوقت الذي شعرنا فيه بأن RethinkDB كان مرضًا ، كنا على ثقة كافية للتوصية باستخدامه في الإنتاج ، سأل الجميع تقريبًا "ما مدى اختلاف RethinkDB عن MongoDB"؟ لقد عملنا بجد لشرح سبب أهمية البساطة والبساطة والنظامية / التوافق ، ولكن في النهاية ، لم تكن هذه العوامل معايير فائدة تهم معظم المستخدمين.
أن نكون صادقين ، هذا مؤلم. انه لامر مؤلم حقا. كان هذا غير مفهوم بالنسبة لنا ، لماذا اختار الناس نظامًا بالكاد يفعل الشيء الذي يجب أن يفعله (تخزين البيانات) ، يحجب النواة ، هو مبعثر بالأخطاء ، وظائف كنقطة واحدة تتوقف عن العمل عند التجزئة ، لديه نظام تجزئة بالكاد ، على الرغم من حقيقة أن هذا هو أحد الميزات الرئيسية للمنتج لا يضمن التشغيل الصحيح ويطرد مجموعة من الواجهات التي لا توجد فيها رؤية منهجية أو موحدة.
في كل مرة تصدر MongoDB بيانًا وهنأهم الناس على التحسينات ، شعرت بارتياح كبير. قالوا إنهم سيصلحون BKL ، لكنهم في الواقع خفضوا مستوى التفاصيل من قاعدة البيانات إلى المجموعة. لقد أضافوا مزيدًا من العمليات ، لكن بدلاً من واجهة نمطية مقترنة بالنظام ، قاموا ببساطة بتفكيك الأوامر لمرة واحدة. سيكون لديهم تجزئة أفضل ، ولكن كان من الواضح أنهم لا يريدون أو لا يستطيعون حتى تقديم ضمانات أولية حول تناسق البيانات.
ولكن مع مرور الوقت ، تعلمت أن أقدر حكمة الحشد. حول MongoDB المطورين العاديين إلى أبطال
عندما احتاج الناس إليها ، وليس بعد سنوات. هذا جعل مستودع البيانات سريعًا ومكن الأشخاص من تقديم المنتجات بسرعة. ومع مرور الوقت ، نمت MongoDB. واحدًا تلو الآخر ، قاموا بإصلاح مشكلات الهندسة المعمارية ، وهو الآن منتج رائع. قد لا يكون وسيمًا كما نود ، لكنه يؤدي وظيفته ويفعله جيدًا.
عندما أصبح من الواضح في منتصف عام 2014 أننا لا نستطيع المنافسة ، عملنا بجد لنكون مختلفين عن MongoDB. لقد وجدنا طريقة أنيقة جدًا لإضافة
إشعارات في الوقت الفعلي ، على أمل أن يتيح ذلك للمطورين إنشاء جيل من التطبيقات لم يتمكنوا من فعله من قبل. لكن هذا لم يكن كافيا. بشكل غير متوقع لأنفسنا ، تحولنا إلى منافسين مع Meteor و Firebase ، الشركات التي كرست نفسها لحل المشكلات الملحة ، والتي لن يتم مناقشتها لعدة سنوات. ومرة أخرى كنا وراء السوق ثلاث سنوات ، مرة أخرى وجدنا أننا لم نتمكن من المنافسة.
ماذا عن السحابة؟
اقترح عدة أشخاص أننا بحاجة إلى تقديم خدمة سحابية. لقد كان لدينا بالفعل مشروع واحد من هذا النوع قيد التطوير ، لذلك هذا موضوع مثير للاهتمام وأود أن أتناوله.
المشكلة الواضحة في قيام شركة صغيرة بتطوير خدمة سحابية هي أن لديها وضع فشل شائع - إلغاء التركيز. من الصعب تطوير وتوزيع وتشغيل خدمة سحابة متعددة المستأجرين. كل هذا يتطلب خبرة وموارد غير عادية ، لذلك إذا دخلت بالفعل هذا المسار ، فقد تجد أنك تدير اثنين من الشركات الناشئة في وقت واحد. ولكن واجهنا تهديد الوجود ، وخيارات العمل لدينا كانت تنفد بسرعة ، لذلك أعطنا هذه الفكرة فرصة لاطلاق النار. لنفترض في الوقت الحالي أننا سنكون قادرين على دفع هذه الفكرة.
كان منطقنا على النحو التالي. قد يعني اقتراح قاعدة البيانات واحدًا من ثلاثة أشياء: الاستضافة المدارة أو قاعدة بيانات كخدمة (DBaaS) أو نظام أساسي متقدم كخدمة (PaaS). دعنا نعود إلى تحليل التسويق المكتوب على الركبة ، حيث استخدمنا المعلمة 200 ألف دولار / الموظف في الإيرادات السنوية ، وهي نفس
القاعدة التي استخدمناها سابقًا:
| الاستضافة المدارة
| DBaaS
| PaaS
|
شركة
| يؤلف ، mLab
| فاوندب
| تحليل ، Firebase ، نيزك
|
الموظفين
| 30
| 30
| 30
|
الدخل
| أقل من 10 ملايين دولار
| أقل من 10 ملايين دولار
| أقل من 10 ملايين دولار
|
هذه الأسواق صغيرة ، وحتى أصغر من سوق قاعدة البيانات نفسها. ربما يجب أن يكون أحدهم يفضل الآخر؟
الاستضافة المدارة تتكون أساسًا من الحفاظ على قاعدة بيانات AWS للأشخاص. بديل لاستخدام هذه الخدمات هو إنشاء قاعدة بيانات AWS الخاصة بك. إنه ألم ، لكنه ليس بالأمر الصعب. لذلك ، هناك قيود شديدة على كيفية تقييم خدمات الاستضافة المدارة. نظرًا لحقيقة أن Compose.io و mLab تقدمان لشركة MongoDB ، التي تتمتع بترتيب أكبر من العملاء من RethinkDB ، افترضنا أن عرض الاستضافة المدارة لن يكون له تأثير كبير.
تعد قاعدة البيانات كخدمة إصدارًا أكثر تعقيدًا من الاستضافة المدارة ، على سبيل المثال ، تفصل خدمة DBaaS إدارة المضيف تمامًا عن المستخدم. عليك فقط تقديم الطلبات ، ويقوم النظام بمعالجتها. لا تعرف أي شيء عن عدد العقد التي تعمل تحت الغطاء. هذا العمل ليس بسيطًا جدًا: جزئيًا لأن شركات DBaaS يجب أن تتنافس مع العمالقة (مثل DynamoDB و DocumentDB) وجزئيًا لأن العملاء لا يميلون إلى نقل إدارة البيانات إلى الشركات الناشئة تمامًا ، في حين أن هناك العديد من الخيارات والبدائل الأخرى (
هل تعرف شخصًا يستخدم خدمات DBaaS من بدء التشغيل؟) لذا ، فإن اقتراح DBaaS قد تأخر.
كان الخيار الأخير هو تطوير منصة متقدمة كخدمة. لقد اعتقدنا أنها منطقة واعدة ، لأن لدينا ميزة فنية كبيرة فيها. كان على Firebase و Meteor بناء منطق للتطبيق في الوقت الفعلي أعلى MongoDB ، مما يحد بشكل كبير من إمكانات الاستعلام في الوقت الحقيقي والأداء في المستوى المناسب. من ناحية أخرى ، يمكننا التحكم في الرصة على طول الطريق ، لذلك يمكننا تقديم فوائد كبيرة لم تكن متوفرة لـ Firebase و Meteor.
لذلك ، قمنا بتطوير
Horizon وبدأنا العمل على Horizon Cloud ، والتي ستتاح للمستخدمين الفرصة لنشر وتوسيع نطاق تطبيقات RethinkDB / Horizon. إن تطوير ثلاثة مشاريع كبيرة (RethinkDB و Horizon و Horizon Cloud) مع فريق صغير جدًا قد تجاوزنا في النهاية ، وما زلنا لا نستطيع إطلاق خدمة سحابة قبل نفاد أموالنا. ومع ذلك ، فيما يتعلق بفريق التطوير. كانت قريبة جدا جدا.
أسئلة الفوقية
هناك مستوى آخر من التحليل للأسباب الجذرية التي يمكننا الإشارة إليها. لماذا اخترنا سوقًا سيئًا وتحسين المنتج وفقًا للمقاييس الخاطئة؟
عندما كنت طفلاً ، أردت أن أجعل الراديو الخاص بي. قمت بصنع صندوق من الخشب الرقائقي ، ورميت بعض الحطام المعدني من الداخل ، وقمت بتوصيل الصندوق بسلك الطاقة. كان لديّ كتب عن الإلكترونيات في المنزل ، لكن يبدو لي أنني لست بحاجة إليها ، وكان لدي إيمان لا يتزعزع بإمكاني القيام بذلك بنفسي. في النهاية ، قمت ببناء جهاز استقبال يعمل ، لكنني استغرقت عدة سنوات لأفهم أخيرًا أنني بحاجة لتعلم أساسيات الالكترونيات.
كان RethinkDB المبكر مثل هذا قليلاً. لم يكن لدينا حدس للمنتجات والأسواق ، لذلك كان الدافع وراءنا ببساطة فكرة إنشاء شركة ، ولا نفهم حقًا ما كنا نفعله. علاوة على ذلك ، كان لدينا
موقف متفائل لا يصدق. كما يعلم الأطباء أن الهدايا المقدمة من شركات الأدوية لها تأثير إدمان على الأطباء الآخرين ، لكنهم ما زالوا يعتقدون أنهم لا يتأثرون بهذا التأثير ، لذلك اعتقدنا أنه ليس لدينا قوانين اقتصادية ومكون رياضي لممارسة الأعمال التجارية. وبطبيعة الحال ، في النهاية ، هزمتنا الرياضيات.
هل يمكننا فعل شيء لتجنب هذه الأخطاء؟ ليس أكثر مما يمكن أن أفعله كطفل مع هذا الراديو. لم ندرك أننا كنا غير كفؤين ، واستغرق الأمر سنوات حتى يصبح هذا العجز غير واعٍ.
لاحظ العديد من الأشخاص أنه يمكننا تحسين وضعنا إذا قمنا ببناء فريق من ذوي الخبرة على استعداد لدخول السوق. هذا صحيح بنسبة 100 ٪ ، ولكن الوقت لتطويرنا الشخصي لا يتفق مع احتياجات الشركة. في البداية ، لم نكن نعلم أننا نحتاج إلى معرفة وخبرة خبراء في الدخول إلى السوق ، لذلك لم نسعى جاهدين لإدراج ذلك في قائمة الأشياء الضرورية لتشكيل فريق. بحلول الوقت الذي طورنا فيه نوعًا من التفكير يتوافق مع الواقع ، كنا نشعر بالغموض في سوق صعب مليء بالمنافسين الجديرين والمنتج الذي تأخر بثلاث سنوات. بحلول ذلك الوقت ، حتى أفضل فريق صديق للسوق في العالم لم يتمكن من إنقاذنا.
وداعا الأفكار
كثير من الناس غاضبون من السوق لأدوات المطور. يحب المطورون صنع أدوات للمطورين ، لذا فهم يريدون حقًا الشركات التي تصنع أدوات للمطورين أن تزدهر.
لا أريد أن أغفل هذا السوق على الإطلاق - جزئياً لأنني لا أريد التعميم على أساس تجربة واحدة ، والسبب الآخر هو أنني لا أحب أن أقول "من المستحيل القيام به" ، وجزئيًا لأن هناك بعض الاستثناءات القليلة. قام كل من GitHub و MongoDB و Docker بإنشاء شركات رائعة. GitLab والوحدة ويبدو أن أداء جيدا للغاية.
إذا كنت تنوي حقًا إنشاء شركة لتطوير الأدوات ، تابع بحذر. السوق مليء بالبدائل الجيدة. توقعات المستخدم مرتفعة وأسعار منخفضة. النظر بعناية في السعر الذي تقدمه للعميل. تذكر أن الرغبة في أن يكون العالم هكذا ، لا تريد أن تجعل الأمر كذلك.
في عام 2009 ، تحدثنا عن فكرة RethinkDB الأصلية (لم يكن لدينا برنامج حتى الآن) لجمهور المستثمر في يوم العرض التجريبي YCombinator. لقد انتهينا من تقرير الشريحة بثلاث نقاط رئيسية. "إذا كان بإمكانك تذكر ثلاثة أشياء فقط عن برنامج RethinkDB" ، قلنا ، "تذكر هذه". لقد نجحت. لم يتذكر الناس أي شيء من الخطاب ، لكنهم تذكروا ثلاث نقاط في النهاية.
سأنتهي بثلاث نقاط أساسية تستحق التذكر. إذا كان هناك شيء يستحق التذكر من هذه المقالة ، فيجب أن نتذكر هذا:
- اختر سوقًا كبيرًا ، ولكن قم به لمستخدمين محددين.
- تعلم كيف تتعرف على المواهب التي تفتقر إليها ، ثم حرثها في الفريق.
- قراءة الإيكونومست دون فشل. وسوف تجعلك أفضل بشكل أسرع.
[1] لا تقرأ الكثير من هذه الأرقام. لقد قدمت تقديراً تقريبيًا للغاية ، لكن لا يزال يتعين علي إعطاء فكرة عامة عن تكلفة هذه الأخطاء.[2] , , , , , , .