Хабрахабр

[Перевод] RethinkDB: почему мы закрылись

RethinkDB: почему мы закрылись

Я взял некоторое время, чтобы переосмыслить полученный опыт, и сейчас могу его четко изложить.
В ветке обсуждений HN люди описывали множество причин, почему RethinkDB провалился, начиная от необъяснимой извращенности человеческой натуры, хитрых махинаций маркетологов MongoDB и неудачи построить опытную команду, готовую выйти на рынок, заканчивая отсутствием поддержки числовых типов размерностью больше 64-битного float. Когда мы объявили, что RethinkDB закрывается, я пообещал написать критический анализ посмертно. Я обобщил комментарии в списке причин провала, которые были предложены.

Например, высказывание, что мы не научились получать финансовую выгоду, является поверхностным. В некоторых из них есть доля правды, но они скорее представляют из себя симптомы, чем причины. Это утверждение не освещает причин, почему у нас не получилось.

Вероятно, каждая из этих ошибок снизила ценность RethinkDB на один-два порядка. Оглядываясь назад, делаю вывод, что две вещи пошли не так — мы выбрали жесткий рынок и оптимизировали продукт согласно неправильным критериям полезности для пользователя. Поэтому если бы мы правильно сделали одну из этих двух вещей, RethinkDB достиг бы размера MongoDB, и если бы мы осознали оба упущения, мы в конечном итоге достигли бы размеров Red Hat[1].

Жесткий рынок

Наше мышление было приблизительно следующим. Новые компании не строятся на основе решений от Oracle, поэтому есть ниша, в которой есть возможность построить компанию с новой инфраструктурой. Рынок баз данных огромен. Если мы создадим проект, который захватит часть рынка, мы придем к тому, что станем очень успешной компанией.

А наши пользователи имели четкое представление о нас как о компании, занимающейся инструментами с открытым исходным кодом, потому что это именно этим мы и занимаемся. К сожалению, ты выходишь не на тот рынок, о котором думаешь — ты находишься на том рынке, куда тебя относят твои пользователи. Тысячи людей использовали RethinkDB, часть в контексте бизнеса, но большинство хотело платить за пожизненное использование меньше, чем за кружку кофе из Starbucks (то есть, не хотели платить совсем ничего). Что оказалось очень печальным для нас, потому что рынок инструментов с открытым исходным кодом — это один из худших рынков, на котором кто-либо может оказаться.

Ответ в основах микроэкономики. Это не было из-за того, что продукт был настолько хорош, что людям не нужно было платить за поддержку, или потому что программисты не контролировали бюджет или из-за краха капитализма. И пока есть большой спрос, предложение значительно опережает его. Программисты любят разрабатывать инструменты для разработки, часто бесплатно. Количество альтернатив взвинчивается, и цены опускаются до нуля.

6 млрд.~700 сотрудников) и Docker (стоимостью примерно $1 млрд.~300 сотрудников). Чтобы узнать, как это отражается на других компаниях, посмотрим на MongoDB (стоимостью примерно $1. Согласно двум общепринятым правилам, растущие частные компании, разрабатывающие ПО, оцениваются в размере десятикратного ежегодного дохода, и доход на одного сотрудника составляет примерно $200тыс./год. Обе компании абсолютно преобладают на своих рынках. Что означает, что годовой доход MongoDB составляет примерно $140-$160 млн, и годовой доход Docker — около $60-$100млн.

Такие компании, как SalesForce, Palantir или Box (которые сталкивается с жесткой конкуренцией). Это выглядит довольно неплохо, пока не рассматриваем превалирующие B2B технические компании на рынках, которые не являются рынками инструментальных средства разработки. И внезапно MongoDB и Docker начинают выглядеть крошечными.

Если относительно утвердившиеся компании, имеющие партнерства, инфраструктуру распространения и доступ к внушительным счетам, сталкиваются с проблемами роста, что это означает для стартапа, находящегося в стадии прорастания? Хотя это крайне успешные компании.

Если на благодатном B2B рынке стартапу нужно обрабатывать сто лидов, чтобы получить десять возможностей, получить одну продажу, то для стартапа, занимающегося инструментами разработки, это количество умножается на 10. Для нас это означало труднообрабатываемую воронку продаж. У тебя есть доступ к множеству годных перспектив — много людей скачивают твой продукт и взаимодействуют с тобой, но тебе нужно прорваться через чумовое количество лидов, чтобы приблизиться к единственной продаже.

Команда деморализована, становится сложно привлечь инвестиции и нанять лучших профи. Это процесс имеет катастрофические последствия домино. Динамика движения это вопрос жизни и смерти для стартапов, и трудности распространения еще на ранних этапах почти всегда обрекают тебя на верную смерть. В свою очередь, это ограничивает собственные ресурсы, поэтому становится невозможным существенно вложиться в продукт или распространение.

Неправильные критерии полезности

Ну хорошо, рынок плох, но другие компании, занимающиеся инструментами средств разработки, все равно продают в больших объемах. Почему не RethinkDB?

Мы хотели построить элегантный, надежный и красивый продукт, поэтому мы оптимизировались под следующие метрики. Хотя мы ничего не могли сделать с динамикой рынка (кроме того, чтобы заняться чем-то другим), решения по продуктам полностью зависели от нас.

  • Правильность. Мы давали очень высокие гарантии и выполняли их неукоснительно.
  • Простота интерфейса. Мы взяли на себя большинство трудностей реализации, чтобы не усложнять жизнь разработчикам.
  • Единообразие. Мы делали все, начиная от языка запросов, клиентских драйверов, конфигурации кластера, документации, до рекламного текста на обложке как можно более единообразным.

Если это кажется знакомыми, мы взяли эти качества из работы хуже это лучше. Оказалось, что корректность, простота интерфейса, и последовательность являются неправильными критериями полезности для большинства пользователей. Большинство пользователей хотели вместо этого эти три опции:

  • Своевременность. Они хотели, чтоб продукт действительно функционировал, когда он им был нужен, не три года спустя.
  • Ощутимая скорость. Люди хотели, чтобы RethinkDB был быстрым под теми нагрузками, которые пользователи фактически давали, а не только под предлагаемыми, которые приближены к «реальности». Например, они пишут быстрые скрипты, чтобы замерить, сколько нужно, чтобы вставить десять тысяч документов без чтения. MongoDB освоил эти нагрузки превосходно, пока мы боролись в уже проигранном бою обучения рынка.
  • Варианты использования. Мы намеревались сделать хорошую систему базы данных, но пользователи хотели хороший способ сделать X (например, хороший способ сохранять JSON документы из hapi, хороший способ сохранять и анализировать логи, хороший способ создавать отчеты и т.д.).

Это не значит, что мы не старались запускаться быстро, сделать RethinkDB быстрым и выстроить экосистему вокруг него, чтобы делать полезную работу легко. Мы это делали. Но правильное, простое и единообразное программное обеспечение требует много времени. Это обусловило наше отставание от рынка на три года.

Мы упорно работали над тем, чтобы объяснить, почему правильность, простота и системность/совместимость так важны, но в конце концов эти факторы не были критериями полезности, которые имели значение для большинства пользователей. К тому времени, как мы почувствовали, что RethinkDB удовлетворяет поставленным требованиям, мы были достаточно уверены, чтобы рекомендовать использовать его в производстве, почти каждый спрашивал «насколько RethinkDB отличается от MongoDB»?

Очень больно. Если быть честным, это больно. Это было непостижимо для нас, почему люди выбирали систему, которая едва ли делает вещь, которую она должна делать (хранить данные), блокирует ядро, разбрасывается ошибками, функционирует как один узел, который перестает работать при сегментировании, имеет едва работающую систему сегментирования, несмотря на то, что это одна из ключевых фишек продукта, не гарантирует корректную работу и вываливает мешанину интерфейсов, в которых нет системности или единства видения.

Они сказали, что исправят BKL, но на самом деле они опустили уровень глубины детализации от базы данных до коллекции. Каждый раз, когда MongoDB выкатывал релиз и люди поздравляли их с улучшениями, я чувствовал прилив негодования. Им бы улучшить сегментирование, но было очевидно, что они не хотели или не могли дать даже элементарные гарантии о согласованности данных. Они добавили больше операций, но вместо модульного интерфейса который сочетался бы с системой, они просто прикрутили разовые команды.

MongoDB превратили обычных разработчиков в героев, когда людям это было нужно, не годы спустя. Но со временем я научился ценить мудрость толпы. И со временем, MongoDB вырос. Это сделало хранилище данных быстрым и позволило людям быстро поставлять продукты. Может, он не такой красивый, как нам хотелось бы, но он делает свою работу и делает ее хорошо. Одна за другой, они исправили проблемы с архитектурой, и теперь это отличный продукт.

Мы нашли очень элегантный способ добавить уведомления в реальном времени, надеясь, что это позволит разработчикам создать поколение приложений, которые они не могли делать раньше. Когда в середине 2014 года стало ясно, что мы не можем конкурировать, мы упорно работали над тем, чтобы отличаться от MongoDB. Неожиданно для себя мы оказались конкурентами с Meteor и Firebase, компаниями, которые посвящали себя решению насущных проблем, о которых еще несколько лет не будет даже речи. Но этого не было достаточно. И снова мы отставали на три года от рынка, снова мы обнаружили, что не способны конкурировать.

Что насчет облака?

Несколько человек предположили, что нам нужно было сделать облачный сервис. У нас на самом деле было один такой проект в разработке, поэтому это интересная тема, которую я хотел бы охватить.

Разрабатывать, распространять и обеспечивать функционирование мультиарендного облачного сервиса сложно. Очевидной проблемой маленькой компании, разрабатывающей облачный сервис, является то, что у нее включается распространенный провальный режим — расфокусировка. Но мы были перед угрозой существования, и у нас быстро заканчивались варианты действий, поэтому мы дали и этой идее шанс выстрелить. Все это требует неординарного опыта и ресурсов, поэтому если ты действительно вступаешь на эту дорожку, можно обнаружить, что ты управляешь сразу двумя стартапами. Давайте на момент предположим, что у нас бы получилось протолкнуть эту идею.

Предложение по базе данных могло означать одну из трех вещей: управляемый хостинг, база данных как услуга (DBaaS), или расширенная платформа как услуга (PaaS). Наши рассуждения заключались в следующем. Вернемся к тому маркетинговому анализу, написанному на коленке, где мы использовали параметр $200тыс./сотрудника в годовой выручке, то самое правило, которое мы использовали ранее:

Управляемый хостинг

DBaaS

PaaS

Компания

Compose.io, mLab

FaunaDB

Parse, Firebase, Meteor

Сотрудники

~30

~30

~30

Доход

< $10M

< $10M

< $10M

Эти рынки малы, даже меньше, чем сам рынок баз данных. Может, стоило предпочесть один из них другим?

Альтернативой использованию этих сервисов является создание базы данных на AWS самостоятельно. Управляемый хостинг в основном заключается в ведении базы данных на AWS за людей. Поэтому есть жесткое ограничение, как оценивать услуги управляемого хостинга. Это боль, но это не настолько сложно. Учитывая то, что Compose.io и mLab предлагают MongoDB, который имеет на порядок больше клиентов, чем RethinkDB, мы предположили, что предложение управляемого хостинга не окажет особенного эффекта.

Ты просто делаешь запросы, и система обрабатывает их. База данных как услуга — это более сложная версия управляемого хостинга, например, DBaaS сервис полностью отделяет управление узлами от пользователя. Этот бизнес очень не прост: частично потому что DBaaS компаниям приходится конкурировать с гигантами (такими, как DynamoDB и DocumentDB) и частично потому что, клиенты не расположены к полной передаче управления данными стартапу в то время, как есть столько много других вариантов и альтернатив (а вы знаете кого-то, кто пользуется услугами DBaaS от стартапа?) Итак, предложение по DBaaS осталось позади. Ты просто не знаешь ничего о том, сколько узлов запускается под капотом.

Мы думали, что это было многообещающее направление, потому что в нем у нас было огромное техническое преимущество. Последним вариантом было разработать расширенную платформу как сервис. С другой стороны, мы могли контролировать стэк на всем пути, поэтому мы могли предложить значительные преимущества, которые были не доступны Firebase и Meteor. Firebase и Meteor пришлось выстроить прикладную логику в реальном времени поверх MongoDB, что существенно ограничивает возможности запросов в реальном времени и производительность на нужном уровне.

Разработки трех больших проектов (RethinkDB, Horizon, и Horizon Cloud) с очень небольшой командой в конце концов настигли нас, и нам так и не удалось выпустить облачный сервис до того, как у нас кончились деньги. Поэтому мы разработали Horizon и начали работать на Horizon Cloud, с помощью которого у пользователей появилась бы возможность развертывать и масштабировать приложения RethinkDB/Horizon. Они были очень, очень близки. Тем не менее, респект команде разработчиков.

Мета вопросы

Есть еще один уровень анализа основных причин, который мы можем отметить. Почему мы выбрали плохой рынок и оптимизировали продукт по неправильным метрикам?

Я сделал коробку из фанеры, выбросил изнутри какой-то металлический мусор и соединил коробку с шнуром питания. Когда я был ребенком, хотел сделать собственное радио. В конце концов я построил работающий приемник, но мне потребовалось несколько лет, чтоб наконец понять, что мне нужно выучить основы электроники. У меня дома были книги по электронике, но мне казалось, что они мне не нужны, у меня была непоколебимая вера, что я могу сделать это сам.

У нас не было интуиции на продукты и рынки, поэтому мы просто были движимы идеей построить компанию, не понимая на самом деле, что мы делаем. Ранний RethinkDB был немного таким. Так же как врачи знают, что подарки от фармацевтических компаний обладают эффектом пристрастия на других врачей, но они все равно верят, что они не подвержены этому эффекту, так и мы думали, что нам ни по чем экономические законы и математическая составляющая ведения бизнеса. Более того, у нас был невероятный оптимистический настрой. И, конечно, в конечном итоге математика и подкосила нас.

Не больше, чем я мог сделать в детстве с тем радио. Могли ли мы сделать что-то, чтобы избежать этих ошибок? Мы не осознавали, что были некомпетентны, и это заняло годы, чтобы эта некомпетентность стала осознанной.

Это 100% правда, но время на наше личное развитие никак не согласовывалось с нуждами компании. Несколько человек отметили, что мы могли бы улучшить свое положение, если бы построили опытную команду, готовую выйти на рынок. К тому времени, как мы выработали тип мышления, который хорошо соотносился с реальностью, мы оказались на мели на жестком рынке, полном достойных конкурентов и продуктом, который отставал на три года. Первоначально мы не знали, что нам нужны были экспертные знания и опыт выхода на рынок, поэтому мы не стремились к тому, чтобы включить это в необходимый список вещей для формирования команды. К тому времени, даже самая лучшая приспособленная к рынку команда в мире не смогла бы спасти нас.

Мысли на прощание

Многие люди возмущаются по поводу рынка инструментов для разработчиков. Разработчики любят делать инструменты для разработчиков, поэтому они очень хотят, чтоб компании, делающие инструменты для разработчиков, процветали.

GitHub, MongoDB, и Docker создали внушительные компании. Не хотел бы опустить этот рынок совсем — частично потому что не хочу обобщать исходя из одного опыта, и частично потому что не люблю говорить «это невозможно сделать» и частично потому что есть довольно много исключений. У GitLab и Unity, кажется, дела тоже идут хорошо.

Рынок полон хорошими альтернативами. Если вы действительно намереваетесь основать компанию по разработке инструментов, действуйте осторожно. Тщательно обдумайте цену, которую вы предлагаете клиенту. Ожидания пользователей высоки, а цены низки. Помните — желание, чтоб мир был таким, вам хочется, не делает его таким.

Мы закончили доклад со слайдами тремя ключевыми пунктами. В 2009 мы рассказывали о первоначальной идее RethinkDB (у нас еще не было ПО) аудитории инвесторов на демонстрационном дне YCombinator. Это сработало. «Если вы сможете запомнить только три вещи о RethinkDB», — мы сказали, «запомните эти». Люди не запомнили ничего из выступления, но они запомнили три пункта в конце.

Если что и стоит запомнить из этой статьи, то стоит запомнить вот это: Закончу тремя ключевыми моментами, которые стоит помнить.

  • Выберите большой рынок, но делайте для конкретных пользователей.
  • Учитесь распознавать таланты, которых у вас не хватает, потом пашите, чтоб заполучить их в команду.
  • Читайте The Economist в обязательном порядке. Это сделает вас лучше быстрее.

[1] Не вчитывайтесь слишком в эти цифры. Я дал совсем приблизительную оценку, но все же должен был дать общее представление о стоимости этих ошибок.

[2] Кстати, распознать людей, компетентных в бизнесе, не имея хорошей деловой интуиции, так же сложно, как и распознать хороших инженеров, не имея интуиции в инженерии.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть