Cloudera fue creada en 2008, cuando empezaba a escucharse el runrún de la expresión Big Data. Hoy es uno de los tres vendedores de distribuciones de software basado en Hadoop [los otros son Hortoworks y MapR]. Con motivo de una conferencia profesional en Londres, el autor de este blog tuvo ocasión de conversar con el CEO de la compañía, Tom Reilly [entrevista que se publicará próximamente] y con Doug Cutting, su chief architect, considerado un padre fundador de Hadoop. El encuentro hizo posible revivir una de esas historias edificantes que depara esta industria siempre y cuando el cronista tome una prudente distancia con los estereotipos de la comunicación corporativa.

Doug Cutting

Antes de transcribir un extracto del diálogo con Cutting, corresponde recordar que el ancestro de Hadoop fue desarrollado por el entrevistado junto con Mike Cafarella [hoy dedicado en exclusiva a la universidad] cuando ambos trabajaban en un proyecto de buscador open source llamado Nutch, iniciado en 2002 y que, cuatro años después, hizo necesario un subproyecto, que el propio Cutting bautizó como Hadoop, nombre que daba su hija a un elefantito de peluche. En marzo de 2006, fichado por Yahoo, creó el primer cluster de una plataforma que se adscribe al movimiento cuyo núcleo es la Apache Foundation. Ha cumplido, pues, diez años, un buen punto de partida para la conversación.

En 2006, cuando Hadoop rompió aguas, usted había sido contratado por Yahoo, donde trabajaban algunos de los que dos años después crearían Cloudera. ¿Imaginaba entonces lo que pasaría como consecuencia de su trabajo?

Lo único que razonablemente podíamos llegar a imaginar era que el fruto de nuestro trabajo se convertiría en un estándar para las compañías web que usaban software open source, pero no que llegaría a ser un estándar global para el software empresarial en tantas industrias. Esto sí que ha sido una buena sorpresa: que compañías bien establecidas, usuarias de software de IBM, de Oracle o de Microsoft, llegarían a adoptar lo que para ellas era inconcebible por ajeno a su experiencia. Por nuestra parte, no esperábamos una confluencia como la que se ha producido entre las dos corrientes. Porque esto es lo que a mi juicio está ocurriendo, y no deja de ser una sorpresa.

Al principio, Hadoop estaba orientado a entornos on-premise, pero sus usos reales han migrado a la nube, pública o híbrida. ¿Qué ha implicado ese tránsito?

No crea que los cambios han sido tantos. La verdad es que desde el primer momento Hadoop corría en Amazon Web Services, que nació por la misma época y lo adoptó rápidamente en su plataforma. El cambio al que usted alude tiene mucho que ver con los usuarios, con compromisos de rendimiento que se han ido imponiendo con el tiempo: si Hadoop se usa en entorno cloud, no hay necesidad de que se le dedique mucha gestión, pero si se usa on-premise es posible configurar el hardware a la manera de cada cual […] Lo cierto es que hoy el uso mayoritario es on-premise pero se ha convertido en la carga más común en la nube. Para quienes hemos contribuído a la construcción de Hadoop, esta diferencia no ha planteado una dificultad, pero la transición ha pesado más sobre los usuarios.

En la base de Hadoop sigue estando HDFS, pero diez años después ya no es la misma plataforma. ¿Cómo describiría la evolución?

Por supuesto que Hadoop ha crecido y ha evolucionado. En su base, como usted ha dicho, está MapReduce, que ha tenido que reescribirse para que HDFS [Hadoop Distributed File System] mejorara sustancialmente. Esto es así, pero la mayor parte de los progresos han tenido lugar fuera de Hadoop, en el ecosistema: ahora hay más motores disponibles, y a los desarrolladores se les han abierto oportunidades que no existían. Spark, desde luego, pero también Kafka, Hive, Impala, Kudu,… son proyectos que han pasado a formar parte del stack, pero sin formar parte de Hadoop propiamente dicho.

Mucha gente opina que Hadoop no es fácil de instalar ni de operar. Lo que es un factor para que el modelo de negocio de sus vendedores se base en los servicios. ¿Le parece justa la crítica? ¿Puede resolverse el problema?

Puedo asegurar que en Cloudera trabajamos para que Hadoop sea más fácil de instalar y de operar. Con este fin hemos construído productos en torno a Cloudera Manager y Cloudera Navigator, para simplificarlo. Pero no hay que olvidar que, en lo fundamental, Hadoop funciona sobre un cluster de máquinas, por lo que necesariamente es más difícil que correr software en una sola máquina […] A veces he pensado que ciertas cosas podrían ser más fáciles de operar, pero con el riesgo de decepcionar al usuario cuando empiece a escalar y aparezcan fallos… mi principio en esta materia es que no todo puede ser automatizado.

Por consiguiente, la formación de los usuarios es crucial y una fuente de ingresos para Cloudera. ¿No es acaso un poco contradictorio con la búsqueda de simplicidad?

Creo entender por dónde va su argumento, pero tenga en cuenta que hablamos de algo que todavía es una tecnología reciente, con la que poca gente está familiarizada. De los estudiantes que ahora están saliendo de la universidad, se puede esperar que en su vida profesional serán capaces no sólo de usar estos sistemas sino también de configurarlos. Para ellos no es un obstáculo como lo es para las generaciones que han trabajado durante años con otra mentalidad.

Han pasado diez años. ¿Diría que Hadoop está suficientemente maduro?

No sería tan concluyente. Podría escaquearme diciendo que diez años no es mucho tiempo, etcétera, pero desde mi punto de vista todo software que no evoluciona pasa a ser moribundo o en esa larga agonía que llaman legacy. La edad de Hadoop no es lo relevante: en cierto modo ha estado maduro desde el principio, pero cada año que pasa aumenta la proporción de quienes lo consideran maduro para usarlo en producción dentro de las grandes organizaciones. Esta es la verdadera prueba de si está maduro o no. Probablemente más de la mitad de las compañías del ranking Fortune 500 usan Hadoop en producción. Aunque para ellas es sólo una porción de su uso actual de las TI. Hay muchas otras compañías en el mundo, más allá de esas 500, que es donde creemos tener asegurado el crecimiento que facilitará la mejora de usabilidad.

Entonces, ¿en qué dirección debería aumentar el potencial de Hadoop?

¿Potencial? En ciertas industrias estamos observando un crecimiento real extraordinario: salud, finanzas, educación, retail, entretenimiento, … Pero en Cloudera no nos proponemos marcar la agenda al mercado. Lo que hacemos es seguir con la mayor atención lo que inventa la comunidad […] Afortunadamente, no estamos en una industria regida por un vendedor único ni por un grupo reducido de vendedores, sino en una industria cuya dirección la determinan los usuarios.

Vale, pero ¿cuáles son los alcances del uso de Hadoop en las empresas?

De todo tipo. Tomemos un ejemplo: Uber usa cloud,… realmente no sé si usa Cloudera, pero sí que usa intensamente Hadoop para optimizar y analizar sus capacidades de servicio. O si prefiere, tomemos otra empresa que está de moda: Tesla puede fabricar mejor sus coches gracias a que monitoriza lo que hacen los usuarios, y esto es lo que le lleva a mejorar continuamente su software. Lo mismo podría decirse de los muchísimos sitios web que optimizan gracias a Hadoop su negocio publicitario. Por mi parte, conozco hospitales que han desarrollado sistemas para reducir la ratio de sepsia […] si me pusiera en plan propagandista, podría presumir de que gracias a Hadoop muere menos gente por infecciones hospitalarias o de que el amor progresa en el mundo gracias a que las webs de ligue online usan Hadoop [risas].

¿Qué proyectos están en marcha para mejorar el ´ecosistema` Hadoop?

Ya he dicho que no marcamos la agenda. En el ´ecosistema` tal como es hoy, sobresale Spark, pero hay más proyectos open source que no son tan notorios. No tienen por qué ser fruto del trabajo de Cloudera, como lo es Impala. Me interesa destacar Kudu, un nuevo motor de almacenamiento que ofrece latencia muy baja y que está ganando popularidad. Un aspecto en el que vemos muchas posibilidades es la necesidad de tener visibilidad de los datos cuando pasan de un sistema a otro u otros: salvo muy raras excepciones, todo el mundo trabaja con tecnologías que no son de última generación, lo que plantea la prioridad de disponer de todos los datos en un determinado sistema y explorarlos con una variedad de herramientas. Otra tendencia que usted sin duda conoce es el empaquetamiento de software en contenedores […]. Como corolario, podría definir el nuevo mundo del software como una confederación de proyectos open source.

No todo es software. ¿Qué influencia espera de las nuevas tecnologías de memoria?

Durante los próximos años, la capacidad de las memorias va a crecer más que la velocidad de las CPU: a este ritmo, debería duplicar a estas y a los discos duros, pero mi impresión es que deberíamos estar preparados para que se multiplique por un factor 10: podremos almacenar muchos más datos activos y podremos construir bases de datos más rápidamente con conjuntos de datos más extensos. Y podremos entrenar a las máquinas en consonancia con esas capacidades superiores. Con las nuevas tecnologías de memoria, que ahora viven una aceleración de propuestas, muchas más aplicaciones serán posibles y asequibles.

Usted ha presidido la Apache Foundation hasta hace unos meses, así que quisiera preguntarle por la vigencia del modelo de distribución open source. ¿Puede una empresa basada en open source ser rentable? Me sobrarían los dedos de una mano para contarlas.

Sin duda es una tarea dura construir un negocio rentable sobre la base del modelo open source, pero este es el modelo de Cloudera, y creo que usted ha hablado del asunto con Tom [Reilly]. A diferencia de lo que hacían los vendedores de software ´propietario`, que controlaban celosamente la evolución de sus plataformas, como forma de preservar su negocio, en el mundo open source es mucho más difícil para una compañía ganarse la vida. Por otro lado, la rapidez con la que está siendo adoptado el software open source se explica porque está disponible, es más barato y mejora la productividad de las empresas. Como su evolución no está controlada por un puñado de vendedores, desaparecen los frenos a la innovación. Le diré más: en diez años de vida de Hadoop, se han visto más mejoras que en los treinta años de las bases de datos relacionales.

Pero eso no elimina la necesidad de vendedores y de otros modelos de negocio…

No, claro que no. De ninguna manera esperamos que los usuarios se las arreglen solos para desarrollar software, ni tampoco confundimos open source con la desaparición de los vendedores; en este mundo cada uno tiene que encontrar su manera de ganar dinero. Cloudera ha encontrado el suyo, bastante razonable, con el que estamos muy satisfechos.

Las fundaciones Apache y Linux son dos modelos distintos, pese a que se identifican con el movimiento open source. ¿Qué las diferencia, según su experiencia?

Someramente, el modelo Apache está controlado por los usuarios y los desarrolladores, tiene algunas reglas sobre cómo han de funcionar las comunidades, pero estas deciden por sí mismas cómo desarrollar su software. La fundación Linux, en cambio, es juridicamente un consorcio en el que el peso recae en las compañías que contribuyen financieramente a sostenerlo. Por lo tanto, se trata de estructuras diferentes, y los proyectos que soporta cada una muestran las diferencias. Tengo un enorme respecto por la Linux Foundation, pero es notorio que trabaja a instancias de las compañías que la apoyan con el fin de que el desarrollo de software no se aleje sustancialmente de sus intereses. Por comparación, Apache sería … más darwiniana: acepta que los proyectos florezcan o marchiten según sus propios méritos.

Ha emergido una tercera vía, una serie de iniciativas bajo el adjetivo open, en prácticamente todos los segmentos de la industria de TI. Su leit motiv es el desarrollo del mercado, y un ejemplo sería la iniciativa ODP [Open Data Project] de la que forma parte alguna empresa de la galaxia Hadoop, pero no Cloudera. ¿Cómo ve la aparición de esta variante?

A veces me preguntan ´¿cómo podría incorporar métodos como los de Apache dentro de mi compañía?´. Mi respuesta es que no creo que el modelo sea transferible: Apache funciona bien porque no hay control jerárquico, porque una diversidad de individuos se ponen de acuerdo pero no tienen un jefe ni responden a un interés económico predeterminado.

¿Qué le ha parecido la sentencia que dio la razón a Google en el litigio planteado por Oracle en torno a Java?

Me ha alegrado que prevaleciera el punto de vista de Google. Se hubiera creado un precedente terrible si a las API no se les reconociera el atributo de uso justo y equitativo […] Yendo un poco más allá, la lección que saco del episodio es que todavía no disponemos de un precedente legal que establezca con claridad que las API pueden ser materia para la ingeniería inversa y no deberían ser patentables.