RethinkDB: por que fechamos

A tradução do artigo foi publicada com permissão do autor.

Quando anunciamos que o RethinkDB estava sendo encerrado, prometi escrever uma crítica póstuma. Demorei um pouco para repensar a experiência e agora posso afirmar claramente.

No tópico de discussão do HN, as pessoas descreveram muitas razões pelas quais o RethinkDB falhou, desde a inexplicável perversão da natureza humana, as maquinações astutas dos profissionais de marketing do MongoDB e o fracasso em criar uma equipe experiente pronta para entrar no mercado, terminando com a falta de suporte para tipos numéricos maiores que o float de 64 bits. Resumi os comentários na lista de razões para falhas que foram sugeridas.

Alguns deles têm alguma verdade, mas são sintomas mais prováveis ​​do que causas. Por exemplo, a afirmação de que não aprendemos como obter ganho financeiro é superficial. Esta declaração não esclarece as razões pelas quais não obtivemos sucesso.

Olhando para trás, concluo que duas coisas deram errado - escolhemos um mercado difícil e otimizamos o produto de acordo com os critérios errados de utilidade para o usuário. Cada um desses erros provavelmente reduziu o valor do RethinkDB em uma ou duas ordens de magnitude. Portanto, se fizéssemos uma dessas duas coisas corretamente, o RethinkDB teria atingido o tamanho do MongoDB e, se tivéssemos percebido as duas omissões, teríamos atingido o tamanho do Red Hat [1].

Mercado difícil

Nosso pensamento foi aproximadamente o seguinte. Novas empresas não são construídas com base em soluções da Oracle; portanto, existe um nicho no qual é possível construir uma empresa com uma nova infraestrutura. O mercado de banco de dados é enorme. Se criarmos um projeto que irá capturar parte do mercado, chegaremos à conclusão de que nos tornaremos uma empresa de muito sucesso.

Infelizmente, você não está entrando no mercado em que está pensando - está no mercado em que seus usuários o levam . E nossos usuários tinham uma visão clara de nós como uma empresa de ferramentas de código aberto, porque é isso que estamos fazendo. O que acabou sendo muito triste para nós, porque o mercado de ferramentas de código aberto é um dos piores mercados em que alguém pode se encontrar. Milhares de pessoas usaram o RethinkDB, parcialmente no contexto dos negócios, mas a maioria queria pagar pelo uso da vida menos do que por uma caneca de café da Starbucks (ou seja, eles não queriam pagar nada).

Isso não ocorreu porque o produto era tão bom que as pessoas não precisaram pagar pelo apoio, ou porque os programadores não controlaram o orçamento ou por causa do colapso do capitalismo. A resposta é o básico da microeconomia. Os programadores adoram desenvolver ferramentas de desenvolvimento, geralmente de graça. E, embora haja uma grande demanda, a oferta está muito à frente. O número de alternativas aumenta e os preços caem para zero.

Para descobrir como isso afeta outras empresas, consulte o MongoDB (no valor de aproximadamente US $ 1,6 bilhão a 700 funcionários) e o Docker (no valor de aproximadamente US $ 1 bilhão a 300 funcionários). Ambas as empresas dominam absolutamente seus mercados. De acordo com duas regras geralmente aceitas, as empresas privadas de software em crescimento são estimadas em dez vezes a renda anual e a renda por funcionário é de aproximadamente US $ 200 mil / ano. O que significa que a receita anual do MongoDB é de cerca de US $ 140 a US $ 160 milhões, e a receita anual do Docker é de US $ 60 a US $ 100 milhões.

Isso parece muito bom até examinarmos as empresas de tecnologia B2B predominantes em mercados que não são de ferramentas de desenvolvimento. Empresas como SalesForce, Palantir ou Box (que enfrentam forte concorrência). E de repente, o MongoDB e o Docker começam a parecer minúsculos.

Embora estas sejam empresas extremamente bem sucedidas. Se empresas relativamente estabelecidas, com parcerias, infraestrutura de distribuição e acesso a contas impressionantes enfrentam desafios de crescimento, o que isso significa para uma startup que está em processo de germinação?

Para nós, isso significava um funil de vendas difícil de alcançar. Se em um mercado B2B próspero, uma startup precisa processar cem leads para obter dez oportunidades, obter uma venda e, para uma startup que trabalha em ferramentas de desenvolvimento, esse número é multiplicado por 10. Você tem acesso a muitas boas perspectivas - muitas pessoas fazem o download do seu produto e interagem com você, mas você precisa romper a praga de leads para se aproximar da única venda.

Este processo tem as conseqüências desastrosas dos dominós. A equipe está desmoralizada, fica difícil atrair investimentos e contratar os melhores profissionais. Por sua vez, isso limita seus próprios recursos, tornando-se impossível investir significativamente em um produto ou distribuição. A dinâmica de direção é uma questão de vida ou morte para as empresas iniciantes, e as dificuldades de distribuição nos estágios iniciais quase sempre o condenam à morte certa.

Critérios de utilidade incorretos

Bem, o mercado está ruim, mas outras empresas envolvidas em ferramentas de desenvolvimento ainda vendem em grandes volumes. Por que não o RethinkDB?

Embora não pudéssemos fazer nada com a dinâmica do mercado (a não ser fazer outra coisa), as decisões de produto dependiam de nós. Como queríamos criar um produto elegante, confiável e bonito, fomos otimizados para as seguintes métricas.

• Correção. Demos garantias muito altas e as cumprimos rigorosamente .
• A simplicidade da interface. Enfrentamos a maioria das dificuldades de implementação para não complicar a vida dos desenvolvedores.
• Uniformidade. Fizemos tudo, desde o idioma da consulta, os drivers do cliente, a configuração do cluster, a documentação e o texto publicitário na capa o mais uniforme possível.

Se parece familiar, tiramos essas qualidades do trabalho; pior, melhor . Descobriu-se que a correção, a simplicidade da interface e a sequência são os critérios incorretos de utilidade para a maioria dos usuários. A maioria dos usuários queria essas três opções:

• Oportunidade. Eles queriam que o produto realmente funcionasse quando precisassem, não três anos depois.
• Velocidade tangível. As pessoas queriam que o RethinkDB fosse rápido sob as cargas que os usuários realmente davam, e não apenas sob as ofertas próximas da "realidade". Por exemplo, eles escrevem scripts rápidos para medir quanto é necessário inserir dez mil documentos sem ler. O MongoDB dominou essas cargas de maneira excelente, enquanto lutávamos em uma batalha de treinamento de mercado já perdida.
• Casos de uso. Pretendíamos criar um bom sistema de banco de dados, mas os usuários queriam uma boa maneira de criar o X (por exemplo, uma boa maneira de salvar documentos JSON do hapi, uma boa maneira de salvar e analisar logs, uma boa maneira de criar relatórios etc.).

Isso não significa que não tentamos iniciar rapidamente, acelerar o RethinkDB e criar um ecossistema em torno dele para facilitar o trabalho útil. Nós conseguimos. Mas o software correto, simples e consistente consome tempo. Isso causou nosso atraso em relação ao mercado em três anos.

No momento em que sentimos que o RethinkDB era satisfatório, estávamos confiantes o suficiente para recomendar usá-lo na produção, quase todos perguntaram "quão diferente é o RethinkDB do MongoDB"? Nós trabalhamos duro para explicar por que correção, simplicidade e sistemicidade / compatibilidade são tão importantes, mas no final, esses fatores não eram critérios de utilidade que eram importantes para a maioria dos usuários.

Para ser honesto, dói. Isso realmente dói. Isso foi incompreensível para nós, por que as pessoas escolheram um sistema que dificilmente faz o que deveria fazer (armazenar dados), bloqueia o kernel, é espalhado por erros, funciona como um nó que para de funcionar durante a segmentação, tem um sistema de segmentação que mal funciona, apesar de O fato de esse ser um dos principais recursos do produto não garante a operação correta e gera uma série de interfaces nas quais não há visão sistemática ou uniforme.

Sempre que o MongoDB lançou um lançamento e as pessoas os parabenizaram pelas melhorias, senti uma onda de indignação. Eles disseram que consertariam o BKL, mas na verdade eles reduziram o nível de detalhe do banco de dados para a coleção. Eles adicionaram mais operações, mas, em vez de uma interface modular combinada com o sistema, eles simplesmente estragaram os comandos únicos. Eles teriam uma melhor segmentação, mas era óbvio que eles não queriam nem podiam dar garantias elementares sobre a consistência dos dados.

Mas, com o tempo, aprendi a apreciar a sabedoria da multidão. O MongoDB transformou desenvolvedores comuns em heróis quando as pessoas precisavam , não anos depois. Isso tornou o data warehouse rápido e permitiu que as pessoas entregassem produtos rapidamente. E com o tempo, o MongoDB cresceu. Um por um, eles corrigiram problemas de arquitetura e agora é um ótimo produto. Ele pode não ser tão bonito quanto gostaríamos, mas ele faz seu trabalho e faz bem.

Quando ficou claro em meados de 2014 que não podíamos competir, trabalhamos duro para ser diferentes do MongoDB. Encontramos uma maneira muito elegante de adicionar notificações em tempo real , esperando que isso permitisse aos desenvolvedores criar uma geração de aplicativos que eles não podiam fazer antes. Mas isso não foi suficiente. Inesperadamente, para nós mesmos, nos tornamos concorrentes da Meteor e da Firebase, empresas que se dedicaram a resolver problemas prementes, que nem sequer serão discutidos por vários anos. E, novamente, estávamos três anos atrás do mercado, novamente descobrimos que não fomos capazes de competir.

E a nuvem?

Várias pessoas sugeriram que precisávamos fazer um serviço em nuvem. Na verdade, tínhamos um projeto em desenvolvimento, então esse é um tópico interessante que eu gostaria de abordar.

O problema óbvio com uma pequena empresa que desenvolve um serviço de nuvem é que ele tem um modo de falha comum - desfocagem. É difícil desenvolver, distribuir e operar um serviço em nuvem com vários inquilinos. Tudo isso requer experiência e recursos extraordinários; portanto, se você realmente entrar nesse caminho, poderá descobrir que gerencia duas startups ao mesmo tempo. Mas estávamos diante da ameaça da existência e nossas opções de ação estavam se esgotando rapidamente, por isso demos a essa oportunidade a chance de disparar. Vamos supor, por enquanto, que possamos promover essa ideia.

Nosso raciocínio foi o seguinte. Uma proposta de banco de dados pode significar uma das três coisas: hospedagem gerenciada, um banco de dados como serviço (DBaaS) ou uma plataforma avançada como serviço (PaaS). Voltemos à análise de marketing escrita no joelho, onde usamos o parâmetro $ 200 mil / funcionário em receita anual, a mesma regra que usamos anteriormente:

	Hospedagem gerenciada	DBaaS	PaaS
Companhia	Compose.io, mLab	Faunadb	Parse, Firebase, Meteor
Funcionários	~ 30	~ 30	~ 30
Renda	<$ 10M	<$ 10M	<$ 10M

Esses mercados são pequenos, ainda menores que o próprio mercado de banco de dados. Talvez você devesse ter preferido um deles ao outro?

A hospedagem gerenciada consiste basicamente em manter um banco de dados da AWS para as pessoas. Uma alternativa ao uso desses serviços é criar seu próprio banco de dados da AWS. É uma dor, mas não é tão difícil. Portanto, há uma restrição severa sobre como avaliar os serviços de hospedagem gerenciada. Considerando que o Compose.io e o mLab oferecem o MongoDB, que possui uma ordem de magnitude em mais clientes que o RethinkDB, assumimos que a oferta de hospedagem gerenciada não teria muito efeito.

Um banco de dados como serviço é uma versão mais complexa da hospedagem gerenciada, por exemplo, um serviço DBaaS separa completamente o gerenciamento de host do usuário. Você acabou de fazer solicitações e o sistema as processa. Você simplesmente não sabe nada sobre quantos nós são executados sob o capô. Esse negócio não é muito simples: em parte porque as empresas DBaaS precisam competir com gigantes (como DynamoDB e DocumentDB) e em parte porque os clientes não estão dispostos a transferir completamente o gerenciamento de dados para as startups, enquanto existem muitas outras opções e alternativas ( Você conhece alguém que usa serviços DBaaS desde uma inicialização?) Portanto, a proposta para DBaaS é deixada para trás.

A opção final foi desenvolver uma plataforma avançada como serviço. Achamos que era uma área promissora, porque tínhamos uma enorme vantagem técnica. O Firebase e o Meteor precisaram criar uma lógica de aplicativo em tempo real sobre o MongoDB, o que limita significativamente os recursos e o desempenho da consulta em tempo real no nível certo. Por outro lado, poderíamos controlar a pilha até o fim, para oferecer benefícios significativos que não estavam disponíveis para o Firebase e o Meteor.

Portanto, desenvolvemos o Horizon e começamos a trabalhar no Horizon Cloud, com o qual os usuários teriam a oportunidade de implantar e dimensionar aplicativos RethinkDB / Horizon. O desenvolvimento de três grandes projetos (RethinkDB, Horizon e Horizon Cloud) com uma equipe muito pequena acabou nos ultrapassando, e ainda não podíamos lançar um serviço em nuvem antes de ficar sem dinheiro. No entanto, respeite a equipe de desenvolvimento. Eles eram muito, muito próximos.

Meta perguntas

Há outro nível de análise das causas raiz que podemos apontar. Por que escolhemos um mercado ruim e otimizamos o produto de acordo com as métricas erradas?

Quando eu era criança, queria fazer meu próprio rádio. Fiz uma caixa de madeira compensada, joguei detritos de metal por dentro e conectei a caixa ao cabo de alimentação. Eu tinha livros sobre eletrônica em casa, mas me pareceu que não precisava deles, tinha uma fé inabalável de que eu mesmo poderia fazer isso. No final, eu construí um receptor que funcionava, mas levei vários anos para finalmente entender que eu precisava aprender o básico da eletrônica.

O RethinkDB inicial era um pouco assim. Como não tínhamos intuição de produtos e mercados, fomos simplesmente movidos pela ideia de construir uma empresa, sem realmente entender o que estávamos fazendo. Além disso, tivemos uma atitude otimista incrível. Assim como os médicos sabem que presentes de empresas farmacêuticas têm um efeito de dependência em outros médicos, mas ainda acreditam que não são afetados por esse efeito, pensamos que não tínhamos leis econômicas nem um componente matemático para fazer negócios. E, é claro, no final, a matemática nos derrubou.

Poderíamos fazer algo para evitar esses erros? Não mais do que eu poderia fazer quando criança com esse rádio. Não percebemos que éramos incompetentes e levou anos para que essa incompetência se tornasse consciente.

Várias pessoas observaram que poderíamos melhorar nossa situação se construíssemos uma equipe experiente e pronta para entrar no mercado. Isso é 100% verdadeiro, mas o tempo para o nosso desenvolvimento pessoal não estava de acordo com as necessidades da empresa. Inicialmente, não sabíamos que precisávamos de conhecimento especializado e experiência para entrar no mercado, por isso não nos esforçamos para incluí-lo na lista necessária de coisas para formar uma equipe. No momento em que desenvolvemos um tipo de pensamento que correspondia bem à realidade, estávamos encalhados em um mercado difícil, cheio de concorrentes dignos e um produto que estava três anos atrás. Até então, mesmo a melhor equipe favorável ao mercado do mundo não poderia nos salvar.

Adeus Pensamentos

Muitas pessoas estão indignadas com o mercado de ferramentas para desenvolvedores. Os desenvolvedores gostam de criar ferramentas para desenvolvedores, então eles realmente querem que as empresas que fazem ferramentas para desenvolvedores prosperem.

Eu não gostaria de omitir esse mercado - em parte porque não quero generalizar com base em uma experiência e em parte porque não gosto de dizer "é impossível fazer" e em parte porque existem algumas exceções. GitHub, MongoDB e Docker criaram empresas impressionantes. GitLab e Unity parecem estar indo bem também.

Se você realmente deseja estabelecer uma empresa de desenvolvimento de ferramentas, continue com cuidado. O mercado está cheio de boas alternativas. As expectativas dos usuários são altas e os preços baixos. Considere com cuidado o preço que você oferece ao cliente. Lembre-se - o desejo de que o mundo seja assim, você o quer, não o faz assim.

Em 2009, conversamos sobre a ideia original do RethinkDB (ainda não tínhamos software) de um público investidor no dia da demonstração do YCombinator. Concluímos o relatório do slide com três pontos principais. "Se você consegue se lembrar de três coisas sobre o RethinkDB", dissemos, "lembre-se delas". Funcionou. As pessoas não se lembraram de nada do discurso, mas se lembraram de três pontos no final.

Terminarei com três pontos-chave que vale a pena lembrar. Se algo vale a pena lembrar deste artigo, vale a pena lembrar o seguinte:

• Escolha um mercado grande, mas faça para usuários específicos.
• Aprenda a reconhecer os talentos que lhe faltam e, em seguida, procure colocá-los na equipe.
• Leia The Economist sem falhas. Isso fará você melhorar mais rápido.

[1] Não leia muitos desses números. Fiz uma estimativa muito aproximada, mas ainda tive que dar uma idéia geral do custo desses erros.

[2] , , , , , , .