Terjemahan artikel ini diterbitkan dengan izin dari penulis.Ketika kami mengumumkan bahwa RethinkDB ditutup, saya berjanji untuk menulis kritik anumerta. Saya meluangkan waktu untuk memikirkan kembali pengalaman itu, dan sekarang saya dapat dengan jelas menyatakannya.
Dalam
utas diskusi HN, orang-orang menggambarkan banyak alasan mengapa RethinkDB gagal, mulai dari penyimpangan sifat manusia yang tidak dapat dijelaskan, penipuan licik pemasar MongoDB dan kegagalan untuk membangun tim berpengalaman yang siap memasuki pasar, diakhiri dengan kurangnya dukungan untuk jenis numerik yang lebih besar dari float 64-bit. Saya telah merangkum komentar pada
daftar alasan kegagalan yang telah disarankan.
Beberapa dari mereka memiliki beberapa kebenaran, tetapi mereka lebih cenderung gejala daripada penyebab. Misalnya, pernyataan bahwa kita belum belajar cara mendapatkan keuntungan finansial adalah dangkal. Pernyataan ini tidak menjelaskan alasan
mengapa kami tidak berhasil.
Melihat ke belakang, saya menyimpulkan bahwa ada dua hal yang salah - kami memilih pasar yang sulit dan mengoptimalkan produk sesuai dengan kriteria kegunaan yang salah bagi pengguna. Masing-masing kesalahan ini mungkin mengurangi nilai RethinkDB dengan satu atau dua urutan besarnya. Oleh karena itu, jika kita melakukan salah satu dari dua hal ini dengan benar, RethinkDB akan mencapai ukuran MongoDB, dan jika kita menyadari kedua penghilangan itu, kita akhirnya akan mencapai ukuran Red Hat [1].
Pasar keras
Pemikiran kami kira-kira sebagai berikut. Perusahaan baru tidak dibangun
atas dasar solusi dari Oracle, jadi ada ceruk di mana dimungkinkan untuk membangun perusahaan dengan infrastruktur baru. Pasar basis data sangat besar. Jika kita membuat proyek yang akan menangkap bagian dari pasar, kita akan sampai pada kesimpulan bahwa kita akan menjadi perusahaan yang sangat sukses.
Sayangnya, Anda tidak memasuki pasar yang Anda pikirkan - Anda berada di pasar tempat
pengguna membawa Anda . Dan pengguna kami memiliki pandangan yang jelas tentang kami sebagai perusahaan alat sumber terbuka, karena itulah yang kami lakukan. Yang ternyata sangat menyedihkan bagi kami, karena pasar alat open source adalah salah satu
pasar terburuk yang dapat ditemukan oleh siapa pun. Ribuan orang menggunakan RethinkDB, sebagian dalam konteks bisnis, tetapi sebagian besar ingin membayar lebih sedikit untuk penggunaan seumur hidup daripada untuk secangkir kopi dari Starbucks (yaitu, mereka tidak ingin membayar apa pun).
Ini bukan karena produknya sangat bagus sehingga orang tidak perlu membayar dukungan, atau karena programmer tidak mengendalikan anggaran atau karena jatuhnya kapitalisme. Jawabannya adalah dasar-dasar ekonomi mikro. Programmer suka mengembangkan alat pengembangan, seringkali gratis. Dan meskipun ada permintaan besar, tawaran itu jauh di depan. Jumlah alternatif
naik , dan harga turun menjadi nol.
Untuk mengetahui bagaimana hal ini memengaruhi perusahaan lain, lihat MongoDB (bernilai sekitar $ 1,6 miliar ~ 700 karyawan) dan Docker (bernilai sekitar $ 1 miliar ~ 300 karyawan). Kedua perusahaan benar-benar mendominasi pasar mereka. Menurut dua aturan yang diterima secara umum, pertumbuhan perusahaan perangkat lunak swasta diperkirakan sepuluh kali lipat pendapatan tahunan, dan pendapatan per karyawan adalah sekitar $ 200 ribu / tahun. Yang berarti bahwa pendapatan tahunan MongoDB adalah sekitar $ 140 - $ 160 juta, dan pendapatan tahunan Docker adalah sekitar $ 60 - $ 100 juta.
Ini terlihat cukup bagus sampai kita melihat perusahaan teknologi B2B yang berlaku di pasar yang
bukan pasar alat pengembangan. Perusahaan seperti SalesForce, Palantir atau Box (yang menghadapi persaingan ketat). Dan tiba-tiba, MongoDB dan Docker mulai terlihat kecil.
Walaupun ini adalah perusahaan yang sangat sukses. Jika perusahaan yang relatif mapan dengan kemitraan, infrastruktur distribusi, dan akses ke akun yang mengesankan menghadapi tantangan pertumbuhan, apa artinya ini bagi startup yang berada pada tahap sprouting?
Bagi kami, ini berarti saluran penjualan yang sulit dijangkau. Jika dalam pasar B2B yang makmur, startup perlu memproses seratus prospek untuk mendapatkan sepuluh peluang, mendapatkan satu penjualan, kemudian untuk startup yang bekerja pada alat pengembangan, jumlah ini dikalikan dengan 10. Anda memiliki akses ke banyak prospek bagus - banyak orang mengunduh produk Anda dan berinteraksi dengan Anda, tetapi Anda harus menerobos wabah timah untuk lebih dekat dengan satu-satunya penjualan.
Proses ini memiliki konsekuensi domino yang menghancurkan. Tim mengalami demoralisasi, menjadi sulit untuk menarik investasi dan merekrut para profesional terbaik. Pada gilirannya, ini membatasi sumber dayanya sendiri, sehingga menjadi tidak mungkin untuk berinvestasi secara signifikan dalam suatu produk atau distribusi. Mengemudi dinamika adalah masalah hidup dan mati untuk pemula, dan kesulitan distribusi pada tahap awal hampir selalu membawa Anda pada kematian.
Kriteria Utilitas yang Salah
Yah, pasarnya buruk, tetapi perusahaan lain yang terlibat dalam alat pengembangan masih menjual dalam volume besar. Mengapa tidak RethinkDB?
Meskipun kami tidak dapat melakukan apa pun dengan dinamika pasar (selain melakukan sesuatu yang lain), keputusan produk sepenuhnya tergantung pada kami. Kami ingin membangun produk yang elegan, andal, dan indah, jadi kami dioptimalkan untuk metrik berikut.
- Kebenaran. Kami memberikan jaminan yang sangat tinggi dan benar - benar mematuhinya .
- Kesederhanaan antarmuka. Kami mengambil sebagian besar kesulitan implementasi agar tidak menyulitkan kehidupan pengembang.
- Keseragaman. Kami melakukan segalanya, mulai dari bahasa permintaan, driver klien, konfigurasi kluster, dokumentasi, hingga teks iklan di sampul selengkap mungkin.
Jika tampaknya akrab, kami mengambil kualitas ini dari pekerjaan,
lebih buruk itu lebih baik . Ternyata kebenaran, kesederhanaan antarmuka, dan urutannya adalah
kriteria kegunaan yang salah bagi sebagian besar pengguna. Sebagian besar pengguna menginginkan tiga opsi ini sebagai gantinya:
- Ketepatan waktu. Mereka ingin produk benar-benar berfungsi ketika mereka membutuhkannya, bukan tiga tahun kemudian.
- Kecepatan nyata. Orang ingin RethinkDB menjadi cepat di bawah beban yang sebenarnya diberikan pengguna, dan tidak hanya di bawah penawaran yang dekat dengan "kenyataan." Misalnya, mereka menulis skrip cepat untuk mengukur berapa yang diperlukan untuk menyisipkan sepuluh ribu dokumen tanpa membaca. MongoDB menguasai beban ini dengan luar biasa sementara kami bertarung dalam pertempuran pelatihan pasar yang sudah hilang.
- Gunakan kasing. Kami bermaksud membuat sistem database yang baik, tetapi pengguna menginginkan cara yang baik untuk membuat X (misalnya, cara yang baik untuk menyimpan dokumen JSON dari hapi, cara yang baik untuk menyimpan dan menganalisis log, cara yang baik untuk membuat laporan, dll.).
Ini tidak berarti bahwa kami tidak mencoba memulai dengan cepat, membuat RethinkDB cepat dan membangun ekosistem di sekitarnya untuk memudahkan pekerjaan yang bermanfaat. Kami berhasil. Tetapi perangkat lunak yang benar, sederhana, dan konsisten memakan waktu. Ini menyebabkan ketertinggalan kami di belakang pasar selama tiga tahun.
Pada saat kami merasa bahwa RethinkDB memuaskan, kami cukup percaya diri untuk merekomendasikan menggunakannya dalam produksi, hampir semua orang bertanya "betapa berbedanya RethinkDB dari MongoDB"? Kami bekerja keras untuk menjelaskan mengapa kebenaran, kesederhanaan, dan sistem / kompatibilitas sangat penting, tetapi pada akhirnya, faktor-faktor ini bukan kriteria kegunaan yang penting bagi sebagian besar pengguna.
Sejujurnya, itu menyakitkan. Sangat menyakitkan. Ini tidak dapat dipahami bagi kita, mengapa orang memilih sistem yang hampir tidak melakukan hal yang harus dilakukan (menyimpan data), memblokir kernel, tersebar oleh kesalahan, berfungsi sebagai satu simpul yang berhenti bekerja ketika melakukan segmentasi, memiliki sistem segmentasi yang hampir tidak berfungsi, meskipun fakta bahwa ini adalah salah satu fitur utama dari produk tidak menjamin operasi yang benar dan membuang banyak antarmuka di mana tidak ada visi yang sistematis atau seragam.
Setiap kali MongoDB meluncurkan rilis dan orang-orang mengucapkan selamat atas perbaikannya, saya merasakan gelombang kemarahan. Mereka mengatakan akan memperbaiki BKL, tetapi pada kenyataannya mereka menurunkan tingkat detail dari database ke koleksi. Mereka menambahkan lebih banyak operasi, tetapi bukannya antarmuka modular yang dikombinasikan dengan sistem, mereka hanya mengacaukan perintah satu kali. Mereka akan memiliki segmentasi yang lebih baik, tetapi jelas bahwa mereka tidak ingin atau bahkan tidak bisa memberikan jaminan dasar tentang konsistensi data.
Namun seiring waktu, saya belajar untuk menghargai kebijaksanaan orang banyak. MongoDB mengubah pengembang biasa menjadi pahlawan
ketika orang membutuhkannya , bukan bertahun-tahun kemudian. Ini membuat data warehouse cepat dan memungkinkan orang untuk dengan cepat mengirimkan produk. Dan seiring waktu, MongoDB telah tumbuh. Satu per satu, mereka memperbaiki masalah arsitektur, dan sekarang produk yang hebat. Dia mungkin tidak setampan yang kita inginkan, tetapi dia melakukan pekerjaannya dan melakukannya dengan baik.
Ketika menjadi jelas pada pertengahan 2014 bahwa kami tidak dapat bersaing, kami bekerja keras untuk berbeda dari MongoDB. Kami menemukan cara yang sangat elegan untuk menambahkan
pemberitahuan waktu nyata , berharap ini akan memungkinkan pengembang untuk membuat generasi aplikasi yang tidak dapat mereka lakukan sebelumnya. Tapi itu tidak cukup. Tanpa diduga untuk diri kita sendiri, kita ternyata menjadi pesaing dengan Meteor dan Firebase, perusahaan yang mengabdikan diri untuk memecahkan masalah mendesak, yang bahkan tidak akan dibahas selama beberapa tahun. Dan lagi kami berada tiga tahun di belakang pasar, lagi-lagi kami mendapati bahwa kami tidak mampu bersaing.
Bagaimana dengan cloud?
Beberapa orang menyarankan agar kami membuat layanan cloud. Kami sebenarnya memiliki satu proyek pengembangan, jadi ini adalah topik menarik yang ingin saya bahas.
Masalah yang jelas dengan perusahaan kecil yang mengembangkan layanan cloud adalah bahwa ia memiliki mode kegagalan umum - defocus. Sulit untuk mengembangkan, mendistribusikan, dan mengoperasikan layanan cloud multi-tenant. Semua ini membutuhkan pengalaman dan sumber daya yang luar biasa, jadi jika Anda benar-benar memasuki jalur ini, Anda mungkin menemukan bahwa Anda mengelola dua startup sekaligus. Tapi kami dihadapkan pada ancaman keberadaan, dan opsi kami untuk bertindak cepat habis, jadi kami memberikan ide ini kesempatan untuk menembak. Mari kita anggap untuk saat ini kita dapat mendorong melalui ide ini.
Alasan kami adalah sebagai berikut. Proposal database dapat berarti satu dari tiga hal: hosting yang dikelola, database sebagai layanan (DBaaS), atau platform lanjutan sebagai layanan (PaaS). Mari kita kembali ke analisis pemasaran yang ditulis di atas lutut, di mana kita menggunakan parameter $ 200 ribu / karyawan dalam pendapatan tahunan,
aturan yang sama yang kita gunakan sebelumnya:
| Hosting yang dikelola
| DBaaS
| PaaS
|
Perusahaan
| Compose.io, mLab
| Faunadb
| Parse, Firebase, Meteor
|
Karyawan
| ~ 30
| ~ 30
| ~ 30
|
Penghasilan
| <$ 10 juta
| <$ 10 juta
| <$ 10 juta
|
Pasar ini kecil, bahkan lebih kecil dari pasar basis data itu sendiri. Mungkin Anda harus memilih salah satu dari yang lain?
Hosting yang dikelola pada dasarnya terdiri dari memelihara database AWS untuk orang-orang. Alternatif untuk menggunakan layanan ini adalah membuat database AWS Anda sendiri. Ini menyakitkan, tetapi tidak
begitu sulit. Oleh karena itu, ada batasan ketat tentang cara mengevaluasi layanan hosting yang dikelola. Mengingat fakta bahwa Compose.io dan mLab menawarkan MongoDB, yang memiliki urutan lebih banyak klien daripada RethinkDB, kami berasumsi bahwa tawaran hosting yang dikelola tidak akan banyak berpengaruh.
Database sebagai layanan adalah versi yang lebih kompleks dari hosting yang dikelola, misalnya, layanan DBaaS sepenuhnya memisahkan manajemen host dari pengguna. Anda hanya membuat permintaan, dan sistem memprosesnya. Anda tidak tahu apa-apa tentang berapa banyak node berjalan di bawah tenda. Bisnis ini tidak terlalu sederhana: sebagian karena perusahaan DBaaS harus bersaing dengan raksasa (seperti DynamoDB dan DocumentDB) dan sebagian karena klien tidak cenderung untuk sepenuhnya mentransfer manajemen data ke startup, sementara ada begitu banyak pilihan dan alternatif lain (
Apakah Anda mengenal seseorang yang menggunakan layanan DBaaS dari startup?) Jadi, proposal untuk DBaaS tertinggal.
Opsi terakhir adalah mengembangkan platform canggih sebagai layanan. Kami pikir itu adalah area yang menjanjikan, karena kami memiliki keunggulan teknis yang besar di dalamnya. Firebase dan Meteor harus membangun logika aplikasi real-time di atas MongoDB, yang secara signifikan membatasi kemampuan permintaan real-time dan kinerja di tingkat yang tepat. Di sisi lain, kami dapat mengendalikan tumpukan sepenuhnya, sehingga kami dapat menawarkan manfaat signifikan yang tidak tersedia untuk Firebase dan Meteor.
Oleh karena itu, kami mengembangkan
Horizon dan mulai bekerja di Horizon Cloud, di mana pengguna akan memiliki kesempatan untuk menyebarkan dan skala aplikasi RethinkDB / Horizon. Pengembangan tiga proyek besar (RethinkDB, Horizon, dan Horizon Cloud) dengan tim yang sangat kecil akhirnya menyusul kami, dan kami masih tidak dapat merilis layanan cloud sebelum kehabisan uang. Namun, hormati tim pengembangan. Mereka sangat, sangat dekat.
Pertanyaan meta
Ada tingkat analisis akar penyebab lain yang bisa kami tunjukkan. Mengapa kami memilih pasar yang buruk dan mengoptimalkan produk sesuai dengan metrik yang salah?
Ketika saya masih kecil, saya ingin membuat radio sendiri. Saya membuat sekotak kayu lapis, melemparkan beberapa puing logam dari dalam, dan menghubungkan kotak itu ke kabel listrik. Saya memiliki buku tentang elektronik di rumah, tetapi bagi saya sepertinya saya tidak membutuhkannya, saya memiliki keyakinan yang tak tergoyahkan bahwa saya dapat melakukannya sendiri. Pada akhirnya, saya membangun receiver yang berfungsi, tetapi butuh beberapa tahun untuk akhirnya memahami bahwa saya perlu mempelajari dasar-dasar elektronik.
RethinkDB awal agak seperti itu. Kami tidak memiliki intuisi untuk produk dan pasar, jadi kami hanya didorong oleh gagasan membangun perusahaan, tidak benar-benar memahami apa yang kami lakukan. Selain itu, kami memiliki
sikap optimis yang luar biasa. Sama seperti dokter tahu bahwa hadiah dari perusahaan farmasi memiliki efek kecanduan pada dokter lain, tetapi mereka masih percaya bahwa mereka tidak terpengaruh oleh efek ini, jadi kami pikir kami tidak memiliki undang-undang ekonomi dan komponen matematika dalam melakukan bisnis. Dan, tentu saja, pada akhirnya, matematika menjatuhkan kami.
Bisakah kita melakukan sesuatu untuk menghindari kesalahan ini? Tidak lebih dari yang bisa saya lakukan sebagai seorang anak dengan radio itu. Kami tidak menyadari bahwa kami tidak kompeten, dan butuh bertahun-tahun untuk ketidakmampuan ini untuk menjadi sadar.
Beberapa orang mencatat bahwa kami dapat memperbaiki situasi kami jika kami membangun tim berpengalaman yang siap memasuki pasar. Ini 100% benar, tetapi waktu untuk pengembangan pribadi kita tidak sesuai dengan kebutuhan perusahaan. Awalnya, kami tidak tahu bahwa kami membutuhkan pengetahuan dan pengalaman ahli dalam memasuki pasar, jadi kami tidak berusaha untuk memasukkan ini dalam daftar hal-hal yang diperlukan untuk membentuk tim. Pada saat kami mengembangkan jenis pemikiran yang sesuai dengan kenyataan, kami terdampar di pasar yang keras penuh dengan pesaing yang layak dan produk yang tiga tahun di belakang. Pada saat itu, bahkan tim ramah-pasar terbaik di dunia tidak dapat menyelamatkan kita.
Selamat Tinggal Pikiran
Banyak orang marah tentang pasar alat pengembang. Pengembang suka membuat alat untuk pengembang, sehingga mereka benar-benar ingin perusahaan yang membuat alat untuk pengembang berkembang.
Saya tidak ingin menghilangkan pasar ini sama sekali - sebagian karena saya tidak ingin menggeneralisasi berdasarkan satu pengalaman, dan sebagian karena saya tidak suka mengatakan "tidak mungkin dilakukan" dan sebagian karena ada beberapa pengecualian. GitHub, MongoDB, dan Docker telah menciptakan perusahaan yang mengesankan. GitLab dan Unity tampaknya berjalan baik juga.
Jika Anda benar-benar berniat mendirikan perusahaan pengembang alat, lanjutkan dengan hati-hati. Pasar penuh dengan alternatif yang baik. Ekspektasi pengguna tinggi dan harga rendah. Pertimbangkan dengan cermat harga yang Anda tawarkan kepada pelanggan. Ingat - keinginan bahwa dunia menjadi seperti ini, Anda menginginkannya, tidak menjadikannya seperti itu.
Pada tahun 2009, kami berbicara tentang ide RethinkDB asli (kami belum memiliki perangkat lunak) dari audiens investor di hari demo YCombinator. Kami menyelesaikan laporan slide dengan tiga poin utama. "Jika Anda hanya dapat mengingat tiga hal tentang RethinkDB," kami berkata, "ingat ini." Itu berhasil. Orang-orang tidak mengingat apa pun dari pidato tersebut, tetapi mereka ingat tiga poin pada akhirnya.
Saya akan mengakhiri dengan tiga poin utama yang perlu diingat. Jika ada sesuatu yang layak diingat dari artikel ini, maka ada baiknya mengingat ini:
- Pilih pasar yang besar, tetapi lakukan untuk pengguna tertentu.
- Belajarlah mengenali bakat yang tidak Anda miliki, lalu bajak untuk memasukkannya ke dalam tim.
- Baca The Economist tanpa gagal. Ini akan membuat Anda lebih cepat lebih baik.
[1] Jangan terlalu banyak membaca angka-angka ini. Saya memberikan perkiraan yang sangat kasar, tetapi masih harus memberikan gambaran umum tentang biaya kesalahan ini.[2] , , , , , , .