Los grandes datos siguen siendo un gran problema, pero ese hecho está un poco oscurecido por los recientes tropiezos de sus antiguos hijos de los carteles: Cloudera, Hortonworks y MapR. Una vez que los queridos de los datos, capaces de levantar enormes montones de dinero en efectivo -Intel bombeó 766 millones de dólares en Cloudera en una sola ronda de inversión- los pesos pesados se han visto obligados a adelgazar, ya sea mediante la fusión (Cloudera y Hortonworks) o el corte de cabezas (MapR).
Mientras tanto, otros grandes proveedores de datos de código abierto como Elastic y MongoDB se están disparando. ¿Qué pasa? Hay, por supuesto, una variedad de razones, entre ellas el hecho de que los antiguos vendedores de Hadoop apostaron mucho por la audiencia equivocada, es decir, los arquitectos vinculados al centro de datos, mientras que el mercado se inclinó por los desarrolladores que buscan la libertad en la nube.
Lo grande es relativo
MapR es la última baja de los vendedores que engordaron con las riquezas de Hadoop. Una vez valorada en más de mil millones de dólares, MapR reveló recientemente que debe despedir a 122 empleados (aproximadamente el 25 por ciento de su base de empleados) incluyendo a su CEO, John Schroeder, otros ejecutivos de alto nivel y muchos ingenieros, y también cerrar la sede central, a menos que pueda encontrar un inversor.
Ese inversor debe firmar antes del 14 de junio o el futuro de MapR se verá sombrío.
Pero entonces, también lo hace su pasado reciente. En los últimos dos años, según datos de LinkedIn, MapR se ha reducido en un 29 por ciento. Y no es el único. Después de combinarse con Hortonworks (presumiblemente porque las dos compañías no podían subsistir solas), Cloudera acaba de anunciar ganancias calamitosas, proyectando entre 69 y 89 millones de dólares menos en ingresos de lo que los analistas estaban proyectando. Al mismo tiempo, el CEO Tom Reilly y el CSO y cofundador Mike Olson anunciaron sus renuncias.
Las acciones cayeron rápidamente un 40 por ciento.
Estos resultados serían más fáciles de atribuir a la realidad volviendo a un mundo de grandes datos sobrevalorados, pero otros vendedores han prosperado, incluso cuando las campanas de Hadoop se han derrumbado. La base de datos MongoDB, por ejemplo, sigue creciendo en popularidad, ahora aproximadamente un tercio tan popular como Oracle y MySQL (medido a través de una variedad de índices), en comparación con un décimo hace sólo cinco años. Esta popularidad, a su vez, sigue impulsando el crecimiento de los ingresos de la empresa homónima, que recientemente ha visto aumentar sus ingresos en un 78%.
Del mismo modo, Elastic, la empresa que está detrás del motor de búsqueda y análisis distribuido Elasticsearch, ha duplicado su plantilla en el último año, mientras que ha visto aumentar sus ingresos en un 70 por ciento en su último trimestre. Las compañías han estado recurriendo a Elastic para la búsqueda de texto tradicional y mucho más, como el Aeropuerto Stansted, utilizando las herramientas de Elastic para rastrear y visualizar el tráfico de personas y equipaje a través del aeropuerto, ofreciendo un análisis en tiempo real.
No era así como se suponía que se debía leer el guión. Tecnologías como MongoDB y Elasticsearch, y las empresas que las respaldan, nunca debieron ser capaces de desafiar a Hadoop y su descendencia. Sin embargo, lo han hecho. ¿Por qué?
Un pronóstico muy nublado
Bueno, la nube es una respuesta, pero es parte de una respuesta multifacética. Como ha escrito el vicepresidente senior de Anaconda, Mathew Lodge, aunque Cloudera, Hortonworks y MapR trataron desesperadamente de evolucionar a partir de las ofertas de las instalaciones, las opciones de nubes de AWS, Microsoft Azure y Google Cloud, todos conspiraron para proporcionar «ofertas totalmente integradas que tienen un menor costo de adquisición y son más baratas de escalar». Las empresas se dieron cuenta. Una vez más, los vendedores de Hadoop se movieron tan rápido como pudieron para construir servicios en la nube, pero simplemente no han igualado el ritmo de sus competidores de la nube.
Continuando con las ventajas de la nube, Hadoop, aunque revolucionaria para su tiempo, es absurdamente cara comparada con las alternativas de la nube. Como Clint Sharp señala, «El principal caso de uso del Hadoop siempre ha sido el almacenamiento barato. [With the cloud] el almacenamiento se hizo más barato y la UX de S3+EMR y otros servicios es 1000 veces mejor». El Hadoop podría haber sido una gran alternativa a los almacenes de datos tradicionales y patentados, por ejemplo, pero no es ni de lejos tan buena como los enfoques más modernos como el Snowflake basado en las nubes.
Al mismo tiempo, la nube anunciaba nuevas y diferentes formas de tratar los datos. Estos no eran reemplazos similares, per se, pero como MongoDB o Elasticsearch, abordaron el mismo tipo de problemas que Hadoop pero sin la dificultad de adormecer la mente. Como dice Joe Drumgoole de MongoDB, «Escribir algoritmos eficaces de reducción de mapas distribuidos es difícil, muy difícil.» Para empeorar las cosas, los vendedores de Hadoop se apresuraron a añadir una amplia gama de complementos de código abierto (Impala! Cerdo! Colmena! Flume!) a sus productos Hadoop, inventando cada vez más engorrosas «pilas de soluciones» hasta que, finalmente, «Nadie sabe qué %&*# hacen estas empresas Hadoop», según un observador.
Para algunas empresas valió la pena el esfuerzo de vadear este gasto en términos de tiempo y atención. En cuanto a los desarrolladores encargados de «hacer las cosas», sin embargo, han optado cada vez más por alternativas más sencillas.
La conveniencia triunfa sobre todo
La experiencia de los usuarios de Hadoop y su progenie es fea. Contrasta esto con MongoDB. La ex ejecutiva de MongoDB Kelly Stirman identifica la experiencia de usuario de MongoDB como un diferenciador clave. ¿Cómo es eso? Tom Barber lo explica:
[With] MongoDB puedes apt install …en un servidor con facilidad y no tener que andar con una terrible máquina virtual para empezar. En la producción, puedes ejecutarlo en un servidor. Puedes conectarlo a un montón de cosas sin escribir un montón de código. La gente quiere bases de datos… MongoDB es fácil de introducir datos, también es fácil de sacar datos.
El director general de TimeScale DB, Ajay Kulkarni, asintiendo con la cabeza, añade:
Amor de desarrollador [is the reason MongoDB trumped Hadoop]. Mongo se centró en la experiencia del primer usuario. Hadoop es notoriamente difícil de dirigir. [Hadoop vendors] tenía un buen argumento de ventas para las empresas, pero sin el amor al desarrollo el crecimiento se estancó y el mercado se evaporó.
Aunque sería exagerado afirmar que el amor de los desarrolladores explica completamente el éxito de MongoDB y Elastic sobre Cloudera y MapR. es un factor real.
Los desarrolladores, según Jake Kaldenbaugh, empezaron a «cocer» MongoDB en sus aplicaciones modernas. Con el tiempo, los desarrolladores que estaban empujando a MongoDB hacia aplicaciones menos críticas las trasladaron a aplicaciones críticas para los negocios, con MongoDB añadiendo funcionalidad (como las transacciones multi-documento) para permitir casos de uso más complicados sin hacerlos tremendamente más complicados.
Entonces, ¿dónde deja eso a los antiguos gigantes de los grandes datos? Lodge ofrece el panegírico:
[A]Después de 10 años de Cloudera y Hortonworks… [and MapR] siendo el centro del universo de Big Data, el centro de gravedad se ha desplazado a otro lugar. Las principales empresas de nubes no dirigen grandes clusters Hadoop/Spark de Cloudera y Hortonworks, sino que dirigen bases de datos y aplicaciones distribuidas a escala de nube sobre la infraestructura de contenedores. Hacen su aprendizaje de máquina en Python, R, y otros lenguajes que no son Java. Cada vez más, las empresas están cambiando a enfoques similares porque quieren cosechar los mismos beneficios de velocidad y escala. Es hora de que el mundo Hadoop y Spark se mueva con los tiempos.
Esta es una de las bendiciones y maldiciones de la innovación de la infraestructura de datos de código abierto. Está sucediendo a una velocidad vertiginosa, y algunos vendedores se quebrarán en el proceso.