javisantana.com

El Software Libre Y Las Empresas

Hay dos extremos en el mundo de las empresas y el software libre: las que lo crean y las que lo usan. En el medio hay otras que son las que contribuyen al que crean otras empresas.

Por ejemplo, si miras las contribuciones del kernel de Linux verás empresas como Redhat, IBM, Facebook que contribuen pero no controlan el proyecto. En mi opinión esto es lo que debería pasar siempre, pero claro, no todos los proyectos tienen una fundación detrás, en este caso Linux Foundation, ni tienen tanto impacto, pero hay otras como Apache fundation que gestionan muchísimos proyectos pequeños. Tampoco hay que ser iluso, es importante mirar el “board of directors” y sobre todo en que empresas trabajan.

Luego tienes empresas como Mongo o Elastic, que crean, guían el proyecto y además tienen un negocio que basan en esa pieza de código. Todos sabemos lo que ha pasado en los últimos años con cambios de licencias de software para evitar que el gran Amazon use su software. Redis, Elastic, Mongo, Mapbox han hecho cambios de licencia relativamente duros para evitar que otras empresas aprovechen su trabajo y les hagan la competencia.

Yo que sigo creyendo en toda esa historia del software libre, pienso que hace avanzar a la humanidad, de hecho me parece que hacer software abierto es una “externalidad positiva” de libro, especialmente si lo haces con consistencia y resuelves un problema, por pequeño que sea. El otro día escuchaba un podcast donde el CEO de databricks, empresa que mantiene Spark, comentaba que su producto era usado por las científicas que han hecho posible la vacuna del puto coronavirus. A su vez spark surge como proyecto aplicando el famoso paper de map reduce de google, de cuando google compartía cosas sin ser marketing vacío. Wikipedia usa kafka (creado por Linkedin), entre otros, para velar que su contenido sea independiente, habilitando uno de los mejores proyectos que seguramente veremos en lo que nos quede de vida (y da igual cuando leas esto). Si eso no es hacer mejor el mundo que baje Dios a decirnos qué es.

Pero la triste realidad es que la mayoría de empresas lo único que hacen es usar ese software libre. Unas pocas colaboran un poco, alguna contribución de vez en cuando y ya. No pasa nada, es lo normal, muchas empresas suficienten tienen con lo suyo.

En CARTO, la empresa que era CTO anteriormente, basabamos nuestra tecnología en open source (y el producto en si también es open source). Sin embargo, aunque sabíamos como funcionaba apenas contribuíamos y eso a la larga terminó pasando factura, porque para innovar necesitas no solo saber como funciona si no cambiar lo que necesitas. Y para cambiar necesitas músculo. Así que para paliar este tema contratamos a los mejores del mundo en ese momento y pusimos unos cuantas personas de la empresa a trabajar 100% en eso.

El caso es que me creo bastante que para que una empresa de tecnología sea puntera tiene que conocer tan bien lo que usa como si lo hicieran ellos mismos. Y esto es como plantar un árbol, cuanto antes lo hagas, mejor. No tengo claro que muchas empresas “deep-tech” se den cuenta de esto a tiempo, una empresa tarda unos años en madurar a todos los niveles y unos años en tecnología es la vida. Echa la vista atrás 10 años y verás a lo que me refiero.

Por eso una de las cosas que estamos haciendo en Tinybird es contratar a gente para aportar 100% a Clickhouse, la base de datos que usamos en nuestro producto. La norma dentro de la empresa es, para entender lo que está pasando, se mira el código fuente, lo demás son conjeturas. No solo se trata de contratar gente, se trata de crear el equipo, la cultura y la dinámica que será la semilla para la mantener la parte de innovar viva dentro de unos años. Estas cosas suelen ser caras, pero más caro es quedarme mirando como otros lo hacen por ti.

Por otro lado, me quema la sangre cuando pensamos que aquí no se pueden hacer estas cosas, pero cuando hablas de tecnología puntera todos los españolitos nos cuadremos mirando a San Francisco (aunque el software open source se desarrolla muchas veces el otro lado del planeta). No es que a mi me importen las banderas o fronteras, pero verás, cuando mejor les vaya a tus vecinos, mejor te irá a tí y sus otros vecinos, también. Por suerte este juego no es de suma cero. Cierto es que en hay una parte importante de cultura y que la industria a tu alrededor cuenta, pero ahora estamos en un punto donde tener a ciertos perfiles es “sencillo” y donde la financiación entiende apuestas así.

Echar A Los Leones

Como “manager” soy lamentable. No es falsa modestia, podéis preguntar a cualquier persona que me haya sufrido como jefe. Hacedlo en privado, en público ya sabéis que nadie dice la verdad, no vayamos a quedar mal. No pasa nada, no hay mejor cosa que asumir tus limitaciones y dejarte de gilipolleces de “superar tus miedos” o “dejar tu zona de confort”.

Y soy malo porque, además de tener un nivel de empatía más bien bajo y tampoco me motiva mucho mejorarlo, la gente me aburre. No me aburre en el sentido “soy un ser superior y tu conversación carente de sustancia intelectual es desmotivante”, más bien en el de “me cuesta estar con gente porque tengo que hacer un esfuerzo extra en no parecer tonto”. Esta escena de “Pulp Fiction” define bastante bien mi relación con las interacciones humanas.

El caso es que, por desgracia, en esta vida te toca ser “manager” en alguna ocasión.

-·-

A mi hija, en edad de ir justito para andar, le gusta bajar y subir escaleras. Las baja por el lado donde no está la barandilla, el cerebro humano a veces tiene estas cosas. Me mata tener que cogerla y bajar las escaleras, porque me cuesta creer que nadie nazca para que le guste cargar con un ser de 15 kilogramos arriba y abajo. Mientras llora y te manda en la dirección contraria a la que vas.

Algún día va a hacerlo sola, se va a calzar la hostia del siglo y me tocará llorar. Eso pensé un día hace unos meses en el que, gracias a la entidad superior que controla este tinglado, justo leía esta maravilla, del libro Art & Fear (que parece de arte pero en realidad habla de la vida), que te pego aquí:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality.

His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: fifty pound of pots rated an “A”, forty pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”. Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity.

It seems that while the “quantity” group was busily churning out piles of work - and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay

Así que me dije, cuantas más escaleras suba y baje, con o sin barandilla, menos probabilidad de que me toque pasar la angustia de esos segundos, que parecen meses de confinamiento, entre que oyes el golpe y empieza a llorar. Y con sinceridad, así me deja un rato tranquilo.

Empecé a dejarla bajar y subir las escaleras. Yo simplemente miraba desde 3 escalones más abajo, para en más de una ocasión cogerla al, literalmente, segundo bote. Meses más tarde me pide que me vaya más abajo, que ella puede sola. Cuando ve las orejas al lobo pone el culo en tierra, porque aprender a usar la barandilla no lo llevamos en los genes, pero lo de ahorrarnos dolor parece que sí. No tengo la certeza de que haya bajado las escaleras ella sola, pero tampoco tengo la duda. Y ese creo que era el objetivo.

-·-

Y me doy cuenta que esa ha sido y es mi estrategia de gestión: echar a los leones tantas veces como sea posible y ver si sobreviven. Cuando sobreviven, y lo hacen la mayoría de las veces, ya no te necesitan, aunque te odien un poco por no haberles ayudado.

Organización de Servicios profesionales

En Tinybird empezamos al revés que muchas empresas de producto: por la parte de monetizar. Antes de meternos 100% a desarrollar producto y luego ir viendo (pivotar lo llaman) decidimos empezar facturando con un producto muy pequeño y haciendo servicios profesionales.

El tema de servicios profesionales es un tema un pelín tabú, ya sabes, la métrica estrella de cualquier SaaS B2B es el MRR (la gallina que entra de forma recurrente al mes) y claro, los servicios profesionales no son, en teoría, recurrentes y tampoco escalan bien. Bien en el sentido de que necesitan personas, y somos caros y tenemos sentimientos, cosa que una máquina en amazon no. Por suerte nuestros clientes son personas y prefieren a alguien humano del otro lado.

Pero la realidad es que la mayoría de productos tienen una parte de servicios profesionales y son necesarios para cerrar clientes que paguen pasta. Hay muchas razones, la más importante es que hemos idealizado tanto las empresas de producto, gracias a esos blog post de americanos vendiendonos el mejor humo, que hemos perdido el norte y nos hemos pasado de vendernos a nosotros mismos.

Pero el troleo, que de verdad me apetece, no es para este post, ahora vengo a hablar de como organizamos internamente la gestión de estos servicios. Sí, es un post sin historia, símplemente te explico aquí lo que hacemos por si te sirve de algo en tu empresa. También lo escribo para mi yo pasado (y futuro, como todo lo que uno escribe), me hubiese gustado que alguien me explicase esto hace 10 años.

Somos una empresa remota, así que todo el proceso intenta ser lo más asíncrono posible. Sería gilipollas si dijese que es 100% asíncrono, pero sin duda molaría mucho más. Por otro lado, toda la gente en servicios profesionales son desarrolladores, nada de “perfiles más baratos”, “más de negocio” o “recursos intercambiables”.

Ahí va, tenemos:

Estas reuniones la mayor parte de las veces son de coordinación técnica-negocio, es decir, siempre hay cosas que hay que negociar, decisiones que pueden afectar para cerrar un cliente, quizá hay que dar un toque a alguno para ver qué tal lo llevan…

Si hay algo que necesita tiempo especial hacemos reunión específica sobre ello previa actualización en su correspondiente proyecto.

Nada nuevo bajo el sol, seguramente la mayor parte de empresas de consultoría tengan un proceso mucho más depurado y haya herramientas maravillosas para este tema, pero la clave está en no olvidar que los servicios profesionales en empresas de producto también necesitan organización y procesos, especialmente 100% remoto.

Tinybird, resumen del año

Casi ya poniendo la guinda al año es un buen momento para parar a recapitular. Y no hay mejor forma de reflexionar y ordenar tu cabeza sobre algo que escribiéndolo. La madre de dios, ni un post sin aroma a Coelho en este blog.

Si llegas aquí sin saber que es Tinybird, es una empresa que fundamos hace un año y pico en la que hacemos un producto que permite analizar cantidades ingentes de datos en tiempo real. Échate un ojo a estos posts que escribí hace tiempo

En los anteriores posts hablaba de tecnología, aquí voy a cambiar el tercio, vamos creciendo y aunque la tecnología sigue siendo ciudadano de primera, hay otras cosas destacables importantes.

Al tajo.

No hemos casi cambiado el stack, prácticamente usamos lo mismo pero estamos haciendo una cosa que normalmente hacen empresas mucho más maduras: refinar. Nuestro stack es sencillo al máximo y eso hace que en vez de hablar de tecnología, hablamos de cómo solucionar problemas con tecnología.

Cuando haces un producto y la gente empieza a usarlo, por muy bueno que seas (incluso les pasa a los norteamericanos) hace aguas. Y lo hace porque los usuarios se meten por caminos que no esperas. Y está pero que muy bien, no hay nada más sencillo a nivel de producto que resolver donde tus clientes tienen problemas porque es precisamente para lo que arrancas tu proyecto,

Hemos subido un escalón. Hemos atacado proyectos de los de quedarse hasta las 3 de la mañana que nos han hecho mejorar. No estoy orgulloso de quedarme hasta las 3 de la mañana, es un error y es síntoma de no saber hacer algo, pero es también el reflejo de que la cosa no era fácil. Si procesar 12 trillones de filas en un solo día no es el siguiente escalón ya no sé qué será.

Hemos crecido el equipo en la primera mitad del año contratando a gente clave y sobre todo, vamos acompañando con procesos y formas que son de empresa mucho más madura. Seguramente el ser 100% remoto hace que sea prácticamente obligatorio, pero que sea la segunda o tercera vez que lo hacemos tenga algo que ver, aunque siempre haces cosas fatal. Seguramente explique en un post las cosas que estamos haciendo diferentes sobre procesos.

Seguimos siendo poquitos (11 según escribo esto) manteniendo la eficiencia. Esto ha pasado en parte porque levantamos el pie al ver el tema del puto virus y por otra porque hemos preferido poner bien el cimiento. La prueba del algodón: podemos dejar un proyecto o feature en manos de cualquier persona del equipo y lo va a sacar adelante con nota.

Además he estado probando alguna nueva forma de contratar y de llegar al público objetivo: streams en twitch hablando de temas técnicos, explicando ofertas de trabajo, haciendo ofertas un poco diferentes…

No hemos hecho ruido (o eso creo). Salir en el periódico, ganar premios y demás está muy bien, te sube la moral, eres el jefe, “putos amos son esta gente”, pero no da de comer ni hace que tu producto sea mejor.

En vez de eso, foco en los clientes: responder rápido, meternos hasta la cocina en sus problemas, entender bien lo que duele. Esta frase también la podría soltar cualquier consultora internacional pero yo no llevo corbata y me puedes preguntar el modelo de datos de cada cliente.

Foco en que el producto sea útil y rápido. En aumentar el ingreso recurrente y la facturación.

Foco en que la gente del equipo vaya cogiendo las partes del negocio fundamentales con onboardings, videos, cursos, trabajo en común y machacar todos los santos días con lo mismo.

Hemos agachado las orejas cuando la hemos liado parda, que ha sido unas cuantas veces.

Cerramos un año bastante bueno a todos los niveles, aunque como siempre miramos mucho más a donde no hemos llegado que a lo que hemos conseguido.

Otra forma de contratar

Mira que me había prometido que no volvería a hablar de cómo contratar pero pensaba que no estaba de más explicar cómo lo hemos hecho esta última vez. Y soy gilipollas porque cuando hice aquella promesa fue porque me dieron por todos los costados (no sé si con razón o no, compruebalo tú misma), y yo soy una persona sensible, me afecta cuando me sacuden.

En general si lees posts de como contratar que hay por ahí terminarás por: 1) contratar a la misma gente que contratan el resto (que puede ser bueno o no) y 2) montando un arco de iglesia tremendo que muy seguramente no necesites para contratar. Estas dos cosas también son aplicables al resto de cosas y así ves empresas con kubernetes y 154 microservicios para aguantar una carga que no despeinaría una raspberri pi alimentada por energía solar.

Y después del anterior párrafo que me podría haber ahorrado, pero que me apetecía meter, pasa que cada empresa y cada momento necesita contratar de una forma (en mi opinión, claro). Y el momento para Tinybird es el de una empresa de 10 personas donde todo el mundo hace casi de todo y que sobretodo, las personas que entren ahora formarán los pilares culturales y serán las referencias de los que vengan detrás de ellas. Si en una casa haces mal un tabique se arregla y punto, si pones mal un cimiento no te imaginas como acaba la historia.

Hasta ahora habíamos tirado de personas cercanas, es decir, personas que eran y siguen siendo para nosotros referencias. Esta es la opción fácil y la mejor al arrancar, pero claro, tiene un problemón: no sales de tu círculo, es más difícil que nadie te venga a decir “pero qué estáis haciendo pin-pin-es” y terminas haciendo todo igual que lo hiciste en el pasado.

Así que en las siguientes contrataciones nos planteamos hacerlas con gente de fuera de nuestros círculos, gente que no conociesemos. Es fácil, es seguir el pesadísimo flujo habitual: sacas una oferta, esperas que llegue gente, los entrevistas y haces una oferta si todo va bien. Sin embargo hay una cosa que valoramos y es que la gente tenga interés por lo que hacemos y no por quienes somos.

Halaga una barbaridad que publiques una oferta de trabajo y te lleguen personas que quieren trabajar contigo símplemente por ser tú, pero la realidad del invento es que tú te conoces mejor que ellos y sabes que el personaje de internet no dice nada del como será el trabajo. Así que para conseguir personas realmente interesadas publiqué un tweet preguntando si la prueba técnica que pedíamos para una supuesta oferta laboral era complicada o no.

Recibí buen feedback de la oferta, pero ese no era el objetivo. Hubo gente que le interesó y se molestó en buscar lo que hacíamos, si buscábamos gente y enviar un correo preguntando. No hay nada mejor que la gente que pregunta (de hecho el test técnico es de preguntar más que de resolver) porque son los que realmente están interesados. Porque ojo, estar interesado en hacer kubernetes con microservicios y loquesea es faćil porque es lo que te dicen en hackernews, pero meterte en una empresa donde se dedican a crear APIs que atacan a billones de registros con tiempos de respuesta de menos de unos pocos cientos de milisegundos no es lo que se ve todos los días.

El resultado ha sido muy bueno: el interés y la calidad de las personas que se han presentado al puesto de backend que buscabamos ha sido altísima y solo nos ha llevado 1 mes cerrar el puesto con muy poco tiempo invertido. Esto parece una payasada que suelto para que la historia termine bien, pero es importantísimo para una empresa que los fundadores puedan ver a los candidatos, ahora, si lleva mucho tiempo al final delegarás eso (y puede que con 50 personas tengas que hacerlo, pero no con 10) porque es un verdadero tostón.

YesCode

El otro día Elon Musk tuiteaba esto (es interesante leer las respuestas, sobre todo las suyas)

No es que Elon sea el más coherente tuiteando ni el que más me guste, pero hay que reconocer que el amigo ha creado algo que hará cambiar industrias completas, que hará que nuestra prole quiera aprender machine learning, física, aeronáutica y otras tantas cosas que estaban dadas por hechas, en vez de ser tiktokeros. No tengo nada en contra de los tiktokteros pero el beneficio de un tiktoktero no es compuesto y sinceramente, no hay tanto espacio para hacer sketchs de especial de nochevieja continuamente.

Me despisto, el caso es que es el CEO de una gran compañía hablando de Inteligencia Artificial con criterio, es decir, sabe qué está diciendo, no son palabras vacías escritas por un comité de discursos para tranquilizar a tu accionariado haciendo ver que estás a la última cuando tu capitalización bursátil se va al garete. Repito, Elon no es el CEO típico y no creo que sea ejemplo de muchas cosas, pero sabe de que habla y pone dinero en ello (porque en software también es cosa de echarle dinero).

Cuando hablamos de transformación digital no tengo muy claro lo que quiere decir, pero creo que se parece mucho más a seguir haciendo lo mismo pero siendo “más digitales”. Cuando yo leo transformación digital lo que pienso es una reestructuración completa de, empezando por el CEO, con un enfoque pensado desde la tecnología. Pero esto, como sabemos es algo casi imposible y seguramente las empresas que hoy nacen digitales serán los nuevos bancos, los nuevos fabricantes de coches, etc.

Sabes que voy a contar una historia, así que no lo demoremos: hace un tiempo tuve la oportunidad de hablar durante un buen rato con el CEO de una empresa top del IBEX35. Yo no soy muy listo pero lo suficiente para saber que cuando yo estaba yendo, él ya había ido y venido media docena de veces. De hecho me quedé impresionado del conocimiento técnico que tenía. La pregunta entonces es, si hay personas tan capaces en puestos muy influyentes, por qué las empresas Españolas, por poner un ejemplo, no terminan de pasar de usar tecnología a ser tecnológicas? la razón -que escribo aquí como si estuviese totalmente seguro de que es así- es que ser alguien sobresaliente no es suficiente, además tienes que entender bien la tecnología (y además todo ese rollo de tener suerte, claro). No me refiero a poder hablar con alguien de tecnología, quiero decir, entender con profundidad la tecnología, tenerla interiorizada. Además, saber de negocio, marketing y otras cosas imprescindibles que todos los libros de emprender describen perfectamente.

Vamos a ilustrar esto con una anécdota, como hace la gente que escribe libros de cientos de páginas. Hace 5 años el CTO, entonces, de Tesla da una charla magistral, no solo por el contenido, si no por saber condensar y explicar la estrategia tecnológica de la empresa de forma tan clara (después de verla piensa si serías capaz de hacer lo mismo con la tuya). Hay una parte de la charla que dice (extracto de los subtítulos de youtube, editado por mi para que se entienda todo a mi favor, si quieres verlo, en vez de leerlo, el extracto empieza aquí):

We've worked with several other make a automotive oems with both Daimler and Toyota and others and it's really fascinating trying to interact with them especially around software electronics because there's a huge fear they just don't totally trust it they don't totally understand it and they kind of treat it like this thing that's to be contained and managed very carefully
There's one story I remember where we had a motor that was controlled by software and there was a concern, what if the motor goes too far [...] what if it over drives in one direction or the other direction, how are we ever gonna prevent that.
We said well can't you know we should just make sure the software doesn't do that and we'll put the appropriate checks and the software and you know write it very carefully and test it.
They said no, you know we can't ever be sure the software will work so they actually put a mechanical bracket around the motor so that they didn't have to care about the software. [...] to me that's kind of just this totally different approach you know if you can't trust the software and you just say you're not even gonna try and make it correct and then put a bunch of mechanical stuff around it you know it's it's a different mindset.

La mejor parte es justo antes de empezar a contar la historia, donde explica el porqué ellos apuestan por el software y dice “this was possible because of the culture of the company”. Eso es, no puede ser de otra manera.

Y para poner la guinda a la historia, sabéis que venía de hacer el menda en cuestión? pues una modificación de un porsche para convertirlo en eléctrico (con un rango de 44km) en 2002. Por favor, si vas a dedicar 2 minutos, que sea a ver como era el prototipo en vez de terminar de leer este post. Es un clarísimo ejemplo de la eficiencia de lo cutre

El problema es que la tendencia actual es ir al extremo opuesto, cuanto menos tengas que saber de programar y de tecnología, mejor. Usemos herramientas “No Code” o “Low Code” (en las que en realidad inviertes tu tiempo en aprender un pseudo lenguaje de programación propietario en vez de invertirlo en aprender algo standard, abierto y que durará más allá de la quiebra de la empresa “no code”), no importa el modo mientras lleguemos al destino, aunque hayamos quemado todos los puentes por el camino. Estas herramientas, los cursos de 3 meses y demás familia tienen su sentido, son muy útiles, pero no creo que nos podamos conformar con ello. No creo que todo el mundo en Tesla sepa como ajustar los parámetros de una red neuronal, pero necesitamos gente que imprima cultura de la tecnología y esa por suerte o desgracia se aprender con esfuerzo y trabajo. Lo peor es que las barreras de entrada en muchas ocasiones las ponemos la propia gente que trabajamos en tecnología, sobre complicando y haciendo tecnología por la mera tecnología.

Aprende a programar, aunque sea un poco.

(Contratar a) la persona correcta

La vida es un conjunto de sube y bajas, algunos baches por el camino -que a veces son pozos- prioridades cambiantes y donde casi todo lo que hacemos viene motivado por una cosa fundamental: las personas que están a nuestro lado.

Puede que sea de forma más o menos egoista, de forma directa o indirecta, da igual que el gobierno sea de derechas o de izquierdas, seas alto o bajo, lista o tonto.

Estos dos párrafos que me acabo de marcar bien podría haberlos escrito Coelho, pero este post en realidad va de contratar gente. A lo mejor podría dedicarme a escribir libros de filosofía “Coelhiana” startrupera, pero podría confundir al público y pensar que no trabajo de verdad. En este blog se escribe sobre lo real.

Hace unos años, cuando empecé a liderar procesos de selección y marcar la estrategia, mi foco era en la excelencia técnica. No quiere decir ni que estuviera equivocado ni que ese fuese mi único objetivo, pero sí era un valor fundamental. De hecho escribí un post sobre como consideraba que había que hacerlo -por el que la policía de internet me lapidó- y del que ya solo estoy en algunas cosas de acuerdo.

Desde aquello han pasado unos años, algunas empresas y un par de historias (las buenas historias siempre vienen de dos en dos) que han cambiado mi forma de mirar las cosas.

Y además te las voy a contar, y lo sabes.

Hace ya siglos en la empresa que trabajaba estábamos en un proceso de “due diligence” típico y parte de ese proceso fue hacer pruebas técnicas a todo el equipo de tecnología. Las pruebas no eran sencillas, eran las típicas pruebas de puzzles y programación de pizarra, que son tan absurdas como inútiles, y que lo único que hacen es aumentar el ego del entrevistador, de hecho un día haré un post sobre cual es mi prueba ideal, pero no nos despistemos ahora.

Al terminar nos dijeron que las pruebas eran horribles (usaría palabras más contundentes pero luego me tachan de negativo), cosa que ya sabíamos después de las pestes que echábamos cuando salíamos de las pruebas (no lo voy a suavizar: pensábamos que eran gilipollas). Pero, vamos a ver, cómo es posible que fuésemos capaces de hacer lo que hacíamos y las pruebas técnicas fuesen tan malas. La explicación era bastante sencilla, estaban evaluando al equipo por separado y no como un equipo. Subestimaban el efecto pegamento del equipo.

La segunda historia es bastante más reciente. Si no lo sabes, te lo digo yo, al entrar en un corporate en un determinado puesto lo primero que hacen es asignarte gente. Es decir, no la buscas tú, estas empresas tienen mucha gente y siempre hay gente que termina proyectos o quiere cambiar de equipo. Montar un equipo y hacerlo funcionar es sencillo, eso lo hace cualquiera, pero coger gente de diferentes equipos, que tú no eliges, y hacerlo funcionar es harina de otro costal.

Así que mi estrategia de solo trabajar con gente “excelente” técnicamente se derrumbó. Entonces recordé la primera historia: si en aquella empresa éramos unos paquetes técnicamente pero luego éramos capaces de producir cosas bastante decentes, tal vez lo de ser excelente pese muchísimo menos a la tener un equipo cohesionado.

Así que manos a la obra me puse a hacer algo que nada tiene que ver con la tecnología: crear buen ambiente, esto es, hacer de ese grupo de personas un equipo haciendo que el ambiente de trabajo fuese bueno, donde hubiese comunicación. Dicho de otro modo, que el buen trabajo fuese el resultado de que la gente se llevase bien.

Entró gente al equipo rechazados de otras áreas, contratamos gente que no pasaba el baremo técnico establecido por el área, hicimos cambios de gente que parecían absurdos, también di la oportunidad de cambiar de equipo a quien no estaban de acuerdo con la forma de trabajar. El resultado, después de 6 meses, fue que el equipo producía, se ayudaban pero sobretodo entendían la situación y necesidades de los demás.

Así que ahora, cuando hago una entrevista, rara vez pregunto algo técnico (aunque el perfil sea puramente técnico) y busco cualidades personales (dentro de lo que mi incapacidad social me permite) que me hagan ver que la persona es de esas que van a tender la mano cuando otra esté en pozo.

Lógicamente tener conocimientos técnicos es muy importante, pero es mejor trabajar con alguien con quien puedes aprender lo que no sabes a con alguien al que miras mientras trabaja.

La Nueva Normalidad

Llevo jugando a simuladores de carreras unos 3 años, me lo tomo bastante en serio dentro de que es un juego, le dedico unas 3-4 horas semanales. Creedme, una carrera de una hora exige una concentración que te deja exhausto. Pero no dejes de leer, esto no va de juegos ni de carreras.

Al principio me apuntaba a carreras con gente que encontraba por internet, simplemente gente que pasaba por allí y quería jugar. Era sencillísimo ganar, simplemente había que esperar a que se salieran de la pista (la mayoría son chavales de 20 años sin cabeza)

Luego pasé a competir en carreras más oficiales con reglas más serias y mejores pilotos, esa gente ya no estaba por estar, le gustaba correr. Pero pasado un tiempo estaba codeandome con los mejores. La sensación era la de ser el “jefazo del volante”.

Pero entonces me apunté a una competición donde había profesionales y pase de estar en top 10 a estar en top 100 (con suerte). Ya no era tan jefazo, de hecho no tenía ni idea de por donde iban el resto para marcar esos tiempos.

La realidad es que entre los mejores y yo solo hay un 1-2% en los tiempos de vuelta. Es decir, como en todo, la calidad no es lineal, llegado un punto para mejorar un 0.1% tienes que invertir 10x en tiempo y esfuerzo.

Para ponerlo en contexto, los mejores hacen 50 milésimas más rápido que yo cada curva. 50 milésimas en 20 curvas que tiene un circuito hace 1 segundo por vuelta que al final de una carrera es una diferencia de 1 minuto. Es decir, la calidad viene de muchos pequeños matices que hasta que no entrenas una y otra vez no eres capaz ni de apreciar.

Repito, la diferencia entre alguien que hace un trabajo de calidad y otro que no, está en detalles que no vas a llegar a apreciar nunca. De hecho, la mayoría de esas veces, esos detalles vienen de conocer y aplicar los fundamentos de lo que estás haciendo.

Al competir con los mejores empecé a hacer las cosas que hacen los mejores, cosas que sin haber estado ahí no se me hubiesen ni pasado por la cabeza: aprovechar ese centímetro de piano, sobrevirar un poco en ciertas curvas para sacar esa décima y otras tantas. Sé que para estar a un nivel que no dé pena en la competición tengo que hacer todo eso, es el mínimo.

Al cabo de meses, vuelves a correr con los que corrías al principio y te da cuenta que, sin ser muy consciente, estás en otro nivel. Tu nueva normalidad es mucho mejor, pero es tu nuevo normal.

Por eso cuando dudas a veces es bueno coger un poco de perspectiva, mirar a los lados y ver si estás o no con los mejores.

Este post también se puede puede resumir en una frase que un día me dijo un buen amigo: nunca vayas a un pueblo peor que el tuyo.

Tecnologia Tinybird

Hace unos meses escribí un post sobre las decisiones que tomamos en tinybird en tecnlogía, este la continuación (y espero ir actualizándolo cada 6 meses). Pero un par de notas antes de empezar.

Para mi producto y tecnología son exactamente la misma cosa. Mejor dicho, forman un conjunto que no tiene sentido separar en una primera fase. Para bien o para mal decisiones que se toman en un sitio afectan a otros en formas totalmente inesperadas. Mejor asumirlo desde el principio y tener en cuenta que no todas las decisiones técnicas son puramente técnicas. Solo el que hace tecnología por la tecnología puede hacerlo así.

En tecnología ya solo hacer que las cosas funcionen es complicado. Nosotros hemos elegido un stack de tecnologías “conservador” porque queremos que las cosas funcionen. No nos movemos por lo que hagan otras empresas, hacemos las cosas porque pensamos que es lo correcto para la nuestra.

De las cosas fundamentales nada ha cambiado especialmente, y esto es de lo mejor que podía pasar.

Seguimos usando solo dos lenguajes backend (python y C++) y javascript en el frontend. Buena decisión que tenemos que mantener. Para algunas cosas python no es lo mejor, C++ no es lo más rápido de desarrollar pero ningún lenguaje es perfecto.

Hemos añadido una pieza grande más al stack de desarrollo: ansible. Por alguna razón, viendo ansible, y habiendo visto chef, algo me dice que el mundo del aprovisionamiento está un pelín roto. Seguramente porque cada proveedor de cloud ha tirado por su lado y que docker nos ha llevado unos 15 años atrás. Pero ansible era sencillo, basado en python y sobre todo, tiene la mayoría de recetas que necesitamos (más en el siguiente punto)

Hemos complicado la arquitectura un poco. En realidad es bastante. Hemos tenido que atacar algunos proyectos en los que necesitabamos escalar bastante y eso requiere más piezas. Los sistemas distribuídos incrementan la complejidad órdenes de magnitud.

Así que ahora tenemos nginx para balancear, redis para la persistencia (con su sentinel), zookeeper para coodinación de replicación y varnish para balanceo y cache (que no usamos ahora mismo). Y clickhouse para almacenar datos, claro.

Pensarás, si usas nginx para qué varnish? bien, conocemos muy bien varnish y nos permite balancear exactamente como queremos (el balanceo de carga lo hacemos en base al análisis del SQL y de los datos en cada máquina para aprovechar localidad de datos y caché, esto daría para otro post). Usamos nginx casi exclusivamente por https, esa es la realidad.

La persistencia que hacemos es un poco diferente a lo habitual. Usamos redis para guardar los datos fundamentales de los usuarios en un formato lo más eficiente para consulta y trabajo desde aplicación (el formato en el que guardamos mapea al modelo de datos de consumición en python) en vez de usar un modelo relacional puro. En clickhouse guardamos todo el histórico de operaciones (un kafka pero a la inversa, para los milenials). Dicho de otro modo, si queremos hacer una consulta sobre lo que ha pasado o hacer analítica vamos a clickhouse. Si vamos a responder una petición de API sobre cuantos datasources tienes vamos a redis (la mayor parte de veces no tocas ni redis).

Ya sea en redis o clickhouse todo tiene esquema. Cuando modelas una aplicación tienes dos momentos de elegir el esquema: cuando guardas o cuando lees los datos. La segunda es como estudiar el día antes del exámen, es mejor ir haciendo el trabajo poco a poco.

La razón de hacer esto así en vez de usar una sola base de datos con todo es: rendimiento y sobre todo poder usar nuestro producto para construir nuestro producto. Toda la analítica que sacamos del propio uso de la plataforma la hacemos con la propia plataforma (de hecho exponemos al usuario parte de esas tablas internas). Podrás pensar que dedicar tiempo al rendimiento es absurdo en una empresa que está validando su modelo, pero tenemos algunos SLA que nos exigen estar por debajo de tiempos de respuesta y aquí necesitas ser rápido y predecible.

Hemos además dividido algunas partes de la aplicación en varios procesos. Fundamentalmente es una decisión para que los despliegues en alta disponibilidad sean más sencillos pero en desarrollo todo sigue siendo un solo proceso maravilloso. Este arranca threads y otros procesos, pero no tienes que gestionar comunicación ni procesos ni todo el cristo de docker-compose punto yamol. En desarrollo no necesitas ni nginx, ni varnish ni flatuas.

Gitlab es una autentica joya. Seguimos usándolo para absolutamente toda la automatización y rara vez nos ha dejado tirados. Además no dependes necesariamente de ellos porque tienes sus “runners” que permiten ejecutar todo en local así que puedes seguir desplegando aunque esté caído. El balance es muy bueno entre el servicio y la autonomía. Es un lujo depender de una sola herramienta para todo el desarrollo. Cada día me gusta más la estrategia que tienen como producto.

Por otro lado durante estos meses hemos encontrado esos problemas que te hacen ver que estás en producción y que cuando están arreglados hacen de un producto un buen producto. El típico fuego que no sabes de donde viene, no entiendes y termina siendo un bug que metiste por algo inesperado.

El numero de bugs registrados ha crecido a más de 100. Hay una categoría especialmente importante que es la de “PAIN”. Hay veces en las que hay pequeñas cosas, que por pequeñas parecen poco importantes, pero que son los que por aculumación terminan por hacer de un producto algo mediocre. Intentamos atacar esos primero, pero lo cierto es que, como siempre, tenemos mucho más trabajo del que podemos atacar.

Durante estos meses también hemos estado desarrollando proyectos. Muchas veces para salir del paso se desarrollan pequeñas herramientas que terminan siendo clave en el producto. No hay nada mejor que lo que desarrollas del fruto de la pura necesidad.

El código por otro lado empieza a tener partes complejas. No solo porque intrinsicamente lo sean, que también, si no porque al ir añadiendo funcionalidad o resolviendo casos extremos generas complejidad. El mayor error de los equipos de desarrollo es no asumir que hay cosas complejas. En vez de asumirlo y tratar de documentarlo, explicarlo y hacer que la gente invierta tiempo en entenderlo, tratan de refactorizar para simplificar sin tener en cuenta que ni lo conocen, ni pueden eliminar la complejidad intrínseca ni que van a añadir otra complejidad diferente.

Hay cosas que son muy importantes que no hemos tenido tiempo de atacar, por ejemplo, casi no hemos contribuído a clickhouse (la base de datos que usamos por debajo), apenas unos commits sueltos.

En resumen, a pesar de intentar mantener todo lo más sencillo posible, hay complejidad que no puedes evitar. Aún somos capaces de gestionar todo entre 3 personas (2 backend + 1 frontend) con consultoría de por medio.

La semana que viene entra la primera persona que contratamos al equipo de desarrollo. Aquí viene el siguiente reto, sobre todo porque es 100% remoto por razones más que obvias (estamos en medio de la cuarentena, por si lees esto en un futuro) y es la primera persona que entra sin haber estado desde el día 0.

Bola Extra

El equipo de Tinybird llevamos ya unos años haciendo aplicaciones de alto rendimiento. El chat de Tuenti, una portada de Google (el making of ), el mapa de la portada del WSJ cuando Obama ganó sus segundas elecciones, gestionado un cluster de cientos de máquinas sirviendo en tiempo real y un largo etcétera.

Durante estos años hemos ido aprendiendo, la mayor parte de veces a base de prueba y error, investigar como funciona el software y hardware y como interactuar con ellos. Nunca habíamos recopilado toda esa información, simplemente era conocimiento que estaba repartido en notas, presentaciones y obviamente nuestras cabezas.

Así que hemos decido crear “principios de analítica en tiempo real para grandes cantidades de datos” un curso que explica, siguiendo nuestros principios de entender como funcionan las cosas, como hacer analítica en tiempo real con grandes cantidades de datos explicado desde las bases.

El curso estaba pensando para hacerlo en persona (de hecho era el onboarding de nuestro primer empleado) pero dadas las circunstancias lo vamos a hacer, resumido, online. Es un curso de fundamentos, no está relacionado con ninguna tecnología concreta. Si explicas las bases con lógica y de manera sencilla, aplicarlo a tu día a día, da igual que uses una base de datos u otra, es trivial.

Lee toda la información y apúntate gratis -hagamos la cuarentena un poco más llevadera- por aquí: Principles of real time analytics on large datasets

Siguiente Decada

No me creo las predicciones, no funcionan. Hay que ser muy chulo para pensar que puedes adivinar el futuro, pero el proceso de pensar qué podría ser importante en el futuro basado en lo que conoces es bastante interesante.

Por otro lado, hacer predicciones es un plan perfecto: si aciertas siempre puedes recuperar tu predicción en el futuro y ponerte la medalla, si no, pues nadie se acordará de tu predicción pero mientras las haces das el pego.

Bueno, al grano: creo que será la década de los límites.

Estamos llegando al límite de emisión de CO2, todos pensabamos que el petroleo se acabaría, pero no, resulta que antes de eso habría tanta carbonilla en el aire que no podríamos ver la luz del sol (y si vives en Madrid seguramente ya te sepas lo de respirar). Bueno, lo ha matado el calentamiento global y que la industria del automóvil ha tocado techo y toca renovar. Qué mejor para un gobierno que toda una industria se renueve. Yo compré acciones de Tesla hace unos meses y guardo a buen recaudo mi seis cilindros en linea porque en 10 años ya dudo que las empresas de coches quieran perder reputación construyendo coches deportivos.

Aprovechando la excusa del CO2 parece que veremos un movimiento (que ya ha empezado agitado por las agencias de marketing) a favor de la sostenibilidad. La realidad es que el ahorro y aprovechamiento siempre ha sido eficiente en términos económicos, otra cosa es que hayamos valorado más la efectividad.

Esto, unido a que estamos llegando al final de la ley de Moore es muy posible que empecemos a ver hardware específico para ciertas cosas. Ya existen GPUs, TPUs (y ya existían DSPs), es posible que veamos hardware específico para tareas web (más allá de balanceadores) y bases de datos (lo mismo volvemos a los mainframes)

Eso o hacemos que los desarrolladores mejoren un orden de magnitud, cosa que no parece que vaya a pasar, seguimos con una demanda altísima de técnicos y eso hace que no sea posible una formación tan profunda como para hacer que seamos realmente buenos.

No obstante, los desarrolladores podemos hacer cientos de cosas para mejorar las emisiones de CO2, echad un ojo a este artículo (del 2015), la lista de ideas es tan larga como interesante.

Otro límite que vamos a tocar es el del vandalismo, por decirlo suave, de los datos. Los grandes han estado haciendo lo que les ha dado la real gana con nuestros datos y es posible que lo sigan haciendo una temporada, el problema es cuando tienes tanto poder que superas al de un gobierno. Europa ya ha ido dando cera a las grandes (con multas irrisorias y unas leyes cosméticas) y en el otro lado ya empezaron hace unos meses con Mark dando explicaciones y siguen ahora. El juicio de Microsoft e internet explorer se va a quedar en anécdota.

Las empresas tendremos que dar cuentas algún día de los datos que usamos, igual que informamos a haciendo de como usamos el dinero. Habrá facturas pero de datos?

En tecnología: todo igual.

Empresas buscarán desarrolladores de React para mantener todo el legacy. Esas mismas estarán negociando los contratos millonarios contratos con Amazon (al estilo oracle) y anunciarán a bombo y platillo como han apagado la última máquina de EC2.

Se buscarán ingenieros que sepan como usar EC2, lo más probable es que la siguiente remesa de desarrolladores ya solo conozcan entornos basados en kubernetes o similar, empujados por, de nuevo, las grandes para que vayas hacia unos sistemas complejísimos que solo alguien con muchos recursos puede gestionar.

Espero ver más herramientas verticales para desarrolladores. SAP es un ejemplo, pero espero que se parezcan más a unity, la verdad. Más lenguajes especializados(de forma que gente menos técnica pueda acceder a usarlo) y que cubran todo el ciclo para llevar productos a producción (herramientas de desarrollo y debugging, dependencias, publicación y monitorización).

Me encantaría ver como es la década de la estandarización en el software, que el software permite integrarse bien, correr en cualquier sitio y que el vendor lock-in sea algo que haya que buscar en la wikipedia.

Veremos blogposts de empresas explicando que dejaron la nube porque no era rentable y seguramente veremos renacer el onpremise y la nube privada. Espero que veamos más gente haciendo nuevos servidores y sistemas operativos (estoy últimamente viendo el movimiento de los unikernel).

Miles de desarrolladores ruby estarán continuamente excusandose para no parecer que están totalmente fuera de juego. Para entender como será puedes ver a los desarrolladores de java hoy.

El único software que seguirá funcionando será el creado en C/C++, como siempre. Las únicas web que seguirán funcionando serán las creadas en 1990 con HTML básico.

Es posible que en unos años el hype sobre la IA pase y empecemos a verla aplicada en tareas que de verdad importan en vez de optimizar al milímetro sin un mínimo de humanidad. Me creo la IA que es capaz de ayudar al humano no a reemplazarlo, ayudando a entender qué le pasa a un paciente, qué problema tiene un coche, hacer que los formularios web no me pidan 50 campos y me entiendan como si estuviese dando mis datos a una persona. fast.ai creo que está acertando en esa línea, intentando que los que saben del dominio a mejorar sean capaces de usar IA en vez de ser reemplazados por modelos creados por gente que no tiene ni zorra de lo que está modelando.

No veremos coches conduciendo solos, la legislación va demasiado lenta para cambiar en solo 10 años. FYI, hay tractores autónomos en producción hace más de 15 años, aún la legislación los prohíbe en la mayoría de países. Mi única esperanza es que eliminen los coches de las ciudades, mejoren la red de autobuses de forma que sea algo intermedio entre un autobús y un cabify/uber y dejen la autoconducción para carreteras y autovías, más sencilla y donde más eficiencia y beneficio podemos obtener.

Miles de bebés dirán sus primera palabras: “Alexa” y “Siri”

Será también la década de lo distribuído: redes sociales, dinero y trabajo (si yo tuviese dinero invertiría en empresas que hagan herramientas para gestionar el trabajo en remoto). Ojalá el protocolo bittorrent sea un redescubrimiento (o IPFS, o lo que sea, me da igual). Espero que sea la década de la vuelta a las provincias.

Y espero que sea la década que recordemos como la tecnología ayudó a mejorar la salud, que ayude a entender y prevenir lo que hoy no podemos ni entender ni curar y que en 2120 puedan contar cosas como esta.

En el 2030 escribiré (con vim, claro) otro post analizando si acerté o no.

Una Decada

En 2010 empezaba a venir por Madrid a algunas conferencias, la mayoría de ellas eran sobre Rails, el framework web que ya no mola, que por aquel entonces estaban empezando a despuntar (gracias a aquel maravilloso video-demo de DHH del que tenemos tanto que aprender). En aquel entonces fue un soplo de aire fresco, gente que le gustaba lo que hacía, que compartía sin pensar en el retorno, lejos de la casta y lo rancio del desarrollo que había visto hasta esos días. Me empezaban a conocer por el “fulano de los tractores”.

Escribía por aquel entonces en un blog de blogger que había sido comprado por google (me sorprende que no lo hayan cerrado) mi post preferido, hacía algunas demos que me llevarían a trabajar para Vizzuality, después CartoDB, más tarde CARTO. Aún recuerdo perfectamente el momento en el que empecé a trabajar con la gente de Vizzuality, iba a trabajar 2 meses (el contrato era temporal, no se fiaban, con toda la razón) con los mejores de la escena en aquel momento, subir a primera división.

Lo que se llevaba eran nubes de tags, wordpress tunedos, RT manuales, gente hablando de la nube (no ha cambiado esto mucho), startups ofreciendo cosas gratis y nosotros preguntándonos como iban a ganar dinero, hoy ya lo sabemos.

Di alguna de las que serían mis primeras charlas (y creo que las mejores)

Hice lo que creo que ha sido mi mejor trabajo hasta la fecha.

Más tarde dejaba CARTO, pasaba sin pena ni gloria por un banco, vendía agroguía y empezaba Tinybird.

Qué es lo que ha pasado en estos años?

Lo moderno hace 10 años es legacy hoy: Node.js era una plataforma inestable y los más modernos defendían a muerte el paradigma asíncrono (los más viejos ya nos habíamos leído la Beej’s guide 10 años antes) con benchmarks vacíos. Hoy todo ha evolucionado y hasta IBM hace librerías para node.js. Programar en rails es de viejos (que ahora ganan dinero).

El frontend ha explotado: hace 10 años se concatenaban ficheros javascript y hoy hay una docena de herramientas para hacer “bundles”. El desarrollo frontend está más cerca de ser visual basic y está haciendo que la ley de Moore se nos quede corta.

El open source ha pasado a ser una herramienta de marketing. Se acabo la ingenuidad del desarrollador que ponía su trabajo a disposición de los demás por el mero hecho de compartir.

El desarrollador ha pasado a ser ciudadano de primera, se acabó la tiranía de la corbata que han pasado de reirse a tener miedo. Todo el mundo recuerda los sueldos desorbitados de tuenti, hoy hordas de gente no técnica hace cursos comprimidos en 3 meses para sere “developers”. No sé si esto es nuevo, las consultoras daban formación de J2EE hace 15 años a filólogos, pero desde luego el status social es bien diferente. Ahora programar es cool, quien lo iba a decir.

El vendor lock-in ha pasado de ser algo a evitar a estar orgulloso y procamarlo a los 4 vientos. Veremos la siguiente década las quejas de desarrolladores migrando sistemas imposibles de mover fuera de amazon.

Microsoft ha pasado a ser el bueno de la película y a meter Linux dentro de Windows.

Volvemos a repetir la historia. El navegador es la nueva máquina virtual de java, si no leed la descripción de WebAssembly y decidme si no os resulta familiar.

Lo que antes llamaban data mining ahora se llama data science/data engineering y en teoría ha pasado a reemplazar el instinto por un puñado de modelos y a ajustar al céntimo sin un mínimo de humanidad. A mi me gusta llamarlo “optimizar sin escrúpulos”.

Las conferencias técnicas han pasado de ser un medio a un fin.

Dos cosas han venido a cambiar como hacemos hoy las cosas: deep learning y blockchain. Si bitorrent hubiese aparecido en esta década y el protocolo fuese basado en JSON (en vez de un formato eficiente) es posible que hubiese sido otro de esos grandes avances.

Linux ha pasado a ser el dueño del escritorio (en tu android, eso sí)

Los formularios de las webs siguen sin entender a los humanos.

Los sistemas operativos siguen sin resolver la ejecución de aplicaciones distribuídas (de mientras amazon nos vende lambda, un CGI venido a más).

Puedes aprender a hacer cualquier cosa en Youtube, web de universidades y similares. Si ahora tuviese 20 años menos es muy posible que no hubiese hecho una carrera universitaria.

Ha sido la década en la que internet se ha hecho capitalista y a pesar de ello sigue siendo maravillosa.

En tecnología, la década ha sido brutal pero esta charla, que tiene más de filosófico que de técnico, en la que explica el porqué no podemos seguir por el camino actual en cuanto al desarrollo se refiere, no deja de resonarme y espero que esta década sea cuando reencaminemos.

Licencias Software

Hace unos meses me escribe de una empresa para echarles un cable para entender si Clickhouse tenía sentido en su plataforma. Para los que no me hayáis escuchado hablar de Clickhouse (y es raro) es una base de datos analítica, no muy conocida, que tiene la mejor tecnología de datos que he visto en años, desarrollada por Yandex, el Google ruso (y este dato es importante para el devenir del post)

Los rusos son gente hecha de otra pasta a nivel de desarrollo. Mi impresión es que son así de bestias por su formación matemática heredada de la cultura que se forjó en la unión soviética (*) (a la fuerza, pero no entraremos en el cómo). Y este párrafo es pura percepción personal probablemente influída porque últimamente hablo con algunos rusos muy listos, pero seguramente sean tan buenos como los españoles :)

Si echas un ojo al software que usamos todos los días hay algo ruso de por medio. Usas postgres? algunos índices están hechos por rusos, nginx? Creado por un ruso, usas Google? El algoritmo de indexación lo creo un tal Sergey Brin… coge cualquier gran proyecto open source, mira las contribuciones y siempre hay rusos. Compáralo con las españolas (teniendo en cuenta que Rusia tiene 3x población)

Al tema, esta empresa de la que no diré el nombre, pero con un equipo técnico de los más interesantes del panorama startup español, baraja resolver el problema con Clickhouse (entre otros) con un criterio exclusivamente técnico: buscan arreglar el problema con la mejor solución. Pero a la semana del primer correo me escriben de nuevo diciéndome que algunos de sus clientes les habían comentado que usar Clickhouse es un “no” por ser ruso (también hablaban de software chino) y por tanto su proyecto tendría que ir por otro camino con la consecuente consternación del equipo.

No soy abogado y seguro que tienen razones legales o de cualquier otro tipo buenísimas para hacer eso, pero también sé que esos clientes deberían buscar asesoría técnica inmediatamente.

Lo habitual es que cuando tienes una empresa de VC detrás estén muy preocupados por un “exit”. Una de las cosas que podría joder un “exit” es la propiedad intelectual del código, imaginate que has usado código de vaya usted a saber quien y cuando vendes tu empresa reclamen su parte, por eso una de las cosas fundamentales que miran es si tu código usa librerias con licencias virales (cómo GPL) o restrictivas. O incluso uses código sin licencia de un menda de GitHub (ahora entenderás el porqué mucha gente pide en tantos repos poner la licencia). Aquí hay una lista de cosas que un VC suele mirar en una due diligence

Pero no veo que “liability” podría causar un software, código abierto, con licencia Apache 2 por mucho que detrás esté Yandex. Detrás de todo gran producto open source hay una gran empresa. De hecho el modelo mongo o elastic es mucho más peligroso ya que son empresas con grandes cantidades de dinero VC que viven exclusivamente de ese software (al contrario que Yandex), y ya sabéis, cuando empiezan a apretar las ganas de ganar dinero el VC ya no es tan divertido y a veces se estira demasiado la cuerda (que se lo digan a meetup.com)

Pero cabría la posibilidad de que estos rusos metieran, ordenados por su gobierno, unos caballos de Troya en su código. Podría, pero la historia reciente nos dice que es más fácil que llegue por un módulo npm o un ataque dirigido (que se lo digan a Everis) y que no hace falta que sean rusos. Podría ser un “huawei” pero no, el código está disponible y no hay un control global, no hablamos de un despliegue para analizar datos en la NSA (he estado leyendo a Snowden últimamente)

Aún me pregunto qué puede pasar por la cabeza de esa gente. A mí me daría mucho más miedo pensar que mi startup tenga los passwords en 1password después de la ronda de $200M a que parte de su stack sea un software open source, escrito por unos rusos brillantes fuera de la politica de la gran empresa donde fue creado (si no es imposible que hubiesen construido algo de tanta calidad). O quizá me preocuparía más que tengan que ir a por una solución cloud, de peor calidad (**) por la cual quizá tengan que doblegar en unos años (que se lo digan a los bancos con HP, IBM u Oracle)

Me desmotiva mucho cuando el dinero puede a la razón. Tal vez en este caso estas empresas tengan poderosas razones pero solo se me ocurre algo tan oscuro que pueda entrometerse en estos temas: la política, empresas del gobierno y al hilo por la “opinión pública”. Como en cualquier tema últimamente puede mucho más la información superficial, posiblemente hidratada con algún que otro bulo, que la capacidad para buscar fuentes de información veraces y con criterio. Si alguien dice que el software ruso es malo, lo será.

Por mi parte seguiré usando software ruso, chino (mirad la lista de contribuciones a tensorflow) o español, si hay una cosa bonita en el software es que nos pone a todos al mismo nivel, no importa si es alemán, español o ruso, escrito por un hombre o una mujer, un alto o un bajo, lo instalas porque te funciona y resuelve un problema.

Bonus track

Estos días estoy escuchando el podcast de inteligencia artificial de Lex Fridman, el amigo no es el más dicharachero, pero las conversaciones son interesantes. Concretamente me ha encantando la primera media hora de conversación sobre lenguajes de programación con Jeremy Howard, fundador de fast.ai

(*) echa un ojo a la lista de matemáticos rusos Especial mención a la cantidad de mujeres en la lista.

(**) Clickhouse está fácilmente 3-4 años por delante de cualquier tecnología cloud hasta que llegue lo nuevo de Google, Procella.

Los Fundamentos

Día a día nos pasamos en la oficina de Tinybird (amablemente proporcionada por Google Campus) discutiendo sobre cachés, índices de base de datos, optimización de lectura en función de la compresión, como funcionaría el sistema en distribuído en función de que datos… nos gusta entender como funciona incluso aunque no sea totalmente necesario.

El 99% de negocios les importa poco ese tipo de cosas, y así está bien, con saber que instalando el framework y usando su API lo tienes solucionado o usando la receta es muchísimo más que suficiente. Hay cientos de miles de negocios que no saben lo que corre por debajo de lo que usan y así debe ser. A nadie se le ocurre tener que saber como funciona un coche para poder conducirlo. De hecho la humanidad no avanzaría si esto no fuese así, nos basamos en el conocimiento que otros ya concentraron.

Pero eso no evita que no tengamos que volver a los fundamentos de vez en cuando. El otro día di un taller de fundamentos de visualización de datos. Mucha gente al principio esperaba empezar a usar “ponga aquí su herramienta” pero no. El curso era de cuales son los conceptos básicos de percepción humana para entender como representar los datos. Por ejemplo, saber que un pie chart es una aberración en la mayoría de casos se entiende perfectamente explicando las bases y 2 ejemplos.

La diferencia entre enseñar a hacer visualización de datos y enseñar los fundamentos es como dar el pescado o enseñar a pescar. Aprender a aplicar los conceptos requiere tiempo, repensar mil veces, equivocarse otras tantas hasta que eres capaz de interiorizarlos y de asentarlos en base a sacar la esencia de cada ejemplo.

Pero no creo que nadie pueda hacer nada realmente bien sin entender las bases. Nadie puede hacer bien ML sin entender las matemáticas que lo fundamentan, no se puede conducir bien sin conocer principios de física de un coche y no se puede hacer bien una query a la base de datos sin saber como funciona por debajo. El problema es que es mucho más sencillo y da más beneficio usar las recetas que en la mayoría de veces funcionan. No habéis visto esos departamentos de marketing ó desarrollo haciendo todo exactamente como viene en el manual sin pensar realmente lo que están haciendo?

Así que cada vez que veo alguien que se entretiene en mirar qué hay debajo, especialmente en el mundo del desarrollo, me da una señal de que esa persona posiblemente sea una buena candidata a ser unos de esas soñados “10x”, de las que en un momento de los delicados te va a sacar del agujero, de las que saben que siempre hay una buena solución (y saben el porqué a veces hay que escoger la mala)

Nunca en mi vida me he arrepentido de haber invertido tiempo en entender como funciona algo, de hecho es posiblemente las mejores inversiones a largo plazo que he hecho. No hay que ser un 10x para hacerlo, ni si lo haces no te convierte en superhéroe, pero necesitamos gente que lo haga.

Bonus track

Relacionado con lo anterior esta charla donde explica como muchas de las cosas que damos por asumidas sobre el rendimiento del hardware actual, no son ciertas y solo basta con mirar lo que hay debajo. En esa línea el famoso You are doing it wrong del creador de Varnish.

El Complejo Del Corporate

He sido muy muy crítico con el corporate durante mi vida profesional, lo sigo siendo, pero últimamente al mismo tiempo trato de entender el porqué están donde están. Después de todo no se consigue facturar cientos o miles de millones de un día para otro por un golpe de suerte.

El corporate sigue teniendo cosas malas no, malísimas: software de pésima calidad (la mayor parte de veces externalizadas) miles de personas que no saben nada y a las que lo de la transformación digital les suena a chino los cuales están normalmente “amparados” por convenios laborales (a pesar de ello bajo ningún concepto eliminaría). Desde el lado startup es lo único que se ve y la razón por la que se menosprecia a la gran empresa.

Pero ojo, Facebook, amazon o cualquier otra empresa gigante (bueno, y cualquier startup de 200 personas) son tan corporate como el más corporate español. No nos engañemos, tienen la ventaja de 20 años menos de legacy, pero los problemas convergen cuando hay muchas personas haciendo lo mismo.

Pero no he venido aquí a hablar de lo que todos ya nos hemos quejado, quiero hablar de esa gente que son los que sacan adelante el trabajo, los que, a pesar de miles de reuniones absurdas son capaces de crear software y hacer esa herramienta que todo el mundo usa y que todo el mundo quiere sustituir por “lo nuevo”.

No hay vez que hable con alguien que trabaje en un corporate español que no te cuenten la historia de un proyecto increíble, que todo el mundo usa pero del que no se habla con orgullo, siempre son “unos cuantos scripts ahí corriendo”. Y aquí es donde fallamos, esos “scripts” que dan servicio a miles o a veces millones de personas son el comienzo de algo. Pero nos quedamos ahí, en cuanto tenemos una solución que funciona tendemos a pensar que es mala. Y lo siguiente es pensar en mantenerla ahí y luego ya haremos el megaproyecto que lo haga “bien”. Esos megaproyectos casi nunca salen bien y finalmente se termina haciendo otra solución que tampoco cumple para no quedar mal. No nos damos cuenta que no es posible hacer algo “bien” sin tener experiencia previa?

Echad un ojo a la historia de React y veréis que empezó como “unos Javascript para resolver una parte”. Pero no se quedaron ahí, avanzaron, lo dieron cariño y han hecho de React un standard. Es un caso especial, pero fijaos en los miles de ejemplos que estos neo-corporates sacan todos los años, dan charlas sobre ellos… ahora, cuantas charlas habéis visto de “"”ponga aquí tu corporate favorito español”””, creéis que son tontos y no son capaces de hacer nada decente, o que realmente falta ese empujón para creerse que haces algo bueno, digno de ser expuesto (y de paso mejorar la empresa en todos los sentidos)

Como en la mayoría de cosas en la vida la perseverancia es lo que hace a algo ser bueno, necesitamos ese cambio cultural que haga que dejemos de pensar en que las cosas son para salir del paso y pensemos que el dorado llegará y pensemos que el dorado se construye, que esa gente que ha construído esa solución que te ha sacado del apuro seguramente haya aprendido y pueda iterar. Y cuando termine la siguiente iteración pueda iterar de nuevo y tal vez generalizar y seguramente empezar a hablar de ello públicamente.

Como Elegimos La Tecnologia Tinybird

Creo mucho en que la mayoría de empresas de tecnología deberían empezar con un servidor de 30€ al mes, con un stack basado en PHP (o unos ficheros HTML y algo como firebase) y en el que el equipo técnico, trabajando mano a mano con negocio, vaya editando directamente en producción hasta tener market fit. Rompe absolutamente todas las buenas prácticas, pero es interesante recordar dos cosas:

1) Tarde o temprano tirarás el primer código (así que cuanto antes mejor)

2) Lo que importa es validar que el negocio tiene sentido no que eres el que mejor arquitectura tienes. Un buen técnico se define también por saber cuando NO invertir tiempo en algo.

Así que todo lo que diga en las siguientes líneas cógelo con pinzas porque ni yo sigo mis propios consejos.

La tecnología acompaña a la empresa

La mayoría de las decisiones tecnológicas que hemos y estamos tomando vienen dadas por la experiencia en CARTO, sobretodo la última fase que viví que fue el cambio hacia B2B. Así que, dado que Tinybird es una herramienta también 100% B2B, de bajo nivel (plataforma) y orientada a trabajar con datos hay una serie de cosas que tuvimos en cuenta antes de arrancar(*):

Algunas de las decisiones

Aquí algunas de las decisiones, sin un orden muy definido, la mayoría de ellas bastante dogmáticas.

Nada de servicios externos. El onpremise es algo que va contra el “sentido común” de un producto SaaS pero a veces ciertas empresas no quieren (o pueden) sacar datos de sus servidores. Y Tinybird es una herramienta que en muchos casos tiene que vivir cerca del origen de los datos. Piensa en tinybird como un nitro para tu base de datos actual, así que tiene que colocarse allí donde haya que acelerar. Esto nos da una ventaja competitiva con respecto a Big Query o Redshift (además de otras muchas que iré comentando en siguientes entregas)

No usamos ni un solo servicio externo, todo funciona en un portátil sin conexión a internet. De hecho una cosa que te permite no depender de servicios de amazon/google/azure es que puedes montar tu producto sobre hardware de verdad. Otro ejemplo de esto es Algolia que decidió usar servidores “de verdad” y aquí explica muy bien las razones. De hecho el poder hacer esto añade una capa de seguridad (nosotros separamos los datos de los clientes de forma física) también muy bien acogida por el corporate. Y obviamente todo mucho más barato que en la nube.

Tenemos que empezar a perder el miedo a explicar que debajo de nuestros servicios hay servidores y recursos finitos cuando los servicios son basados en recursos.

Lo más sencillo posible: relacionado con el anterior, nada de kubernetes nada de miles de servicios. No significa que en la parte SaaS no podamos usarlos, pero evitándolos siempre que se pueda. La aplicación tiene el código para el aprovisionamiento, deployment, tareas como backups y mantenimiento y toda la parte de frontend.

Obviamente solo un repo (salvo una extensión que haremos open source), no creo que tenga sentido tener más de un repo salvo que casos muy específicos, al final tener diferentes repos, aunque suena muy bien, se convierte en un problema de gestión añadido y de integridad de tu sistema.

Todo concentrado en gitlab: repo, tickets, CI, testing. La documentación es el mismo repo. También tenemos el CRM y el blog en gitlab.

Número de dependencias mínimo, es preferible invertir 2 días de trabajo y saber lo que está pasando a usar la dependencia que encuentras en github. Solo usamos dependencias que o bien conocemos o bien hay poco riesgo de que sean un problema por no conocerlas. Se pide perdón cuando haces un commit con una dependencia nueva.

Ahora mismo la aplicación se instala con pip install tinybird.whl y se ejecuta con un tinybird_server. No necesita balanceador, es un solo proceso corriendo en la máquina, punto. Obviamente tenemos un balanceador para tener alta disponibilidad, pero no sería necesario.

Tampoco usamos base de datos al uso, el volumen de usuarios que esperamos no es algo, así que usamos un sistema basado 100% en memoria y almacenamos los datos o bien en disco o en redis (si hay HA). Para la parte analítica guardamos todos los eventos que se producen en la aplicación (obviamente en clickhouse para analizarlo con nuestro propio producto) De esta forma cumplimos con todos las requisitos de trazabilidad que suele requerir el corporate.

Y obviamente esto incluye dejar fuera a los frameworks y toolkits. Usamos las partes que nos interesan de tornado (un framework web muy sencillo) y React. Es cierto que el onboarding técnico se hace difícil encontrar gente, pero es que somos nosotros los que hacemos el framework, nuestro target son precisamente perfiles que les guste saber lo que hay por debajo del framework.

Por otro lado, en mi opinión los equipos de tecnología no escalan bien, este producto está pensado para tener un nucleo de personas muy pequeño (como, en realidad, casi todas las empresas, aunque no lo sepan) y tener los complementos orbitando (tanto en equipo como en tecnología)

La velocidad es clave, así que usamos C++ para las partes críticas (por ejemplo, la construcción de árbol de dependencias SQL o el parsing de CSV) y python para la capa de gestión y partes no tan críticas. Me asombra como la mayoría de las empresas pasan la velocidad por alto pero fijaos en trello, figma o notion

Al hilo de lo anterior y de que teníamos que partir de tecnología existente para acelerar el producto, usamos Clickhouse (una maravilla de la ingeniería). Como ya tenemos una edad para tirarse a la piscina sin mirar si tiene agua, antes de usarla me pegué 1 año estudiando como funcionaba, haciendo pruebas de concepto, probando si era viable contribuir al código, hablando con los desarrolladores y echandoles un cable con el diseño de la parte geospacial. Además, antes de arrancar monté unas charlas y asistí a otras tantas relacionadas con datos para ver como estaba el sector.

El testing: el máximo end to end posible y usando doctest para partes unitarias. Muchas veces la aproximación es prototipo con test mínimos, prueba y luego desarrollo de tests. Por otro lado invertimos más tiempo de testing en lo que consideramos que tiene más valor.

Insistimos mucho en metricar y tener las partes críticas bien medidas. Cuesta poco y así probamos nuestra propia plataforma.

Luego hay otros temas como por ejemplo, no tenemos sistema de usuarios interno, siendo realistas, te ahorras un dolor tremendo en la gestión de usuarios y cualquier empresa va a quererlo integrado con su sistema de autenticación. Quieres además estar integrado con su sistema para eliminar barreras a que más usuarios usen la plataforma.

En general intentamos entender bien lo que usamos, que además sea lo más robusto/probado posible, simplificar todo lo que se puede (teniendo en cuenta que un sistema de datos de por si es complejo) y mantener la burocracia en mínimos pero no tan mínimos que no permita escalar el equipo.

(*) el primer commit es de Febrero de 2018

Fyre Festival

El otro día veía Fyre en Netflix, un documental sobre un festival de música muy bien vendido pero muy mal ejecutado que resultó ser un desastre.

A medida que van pasando las entrevistas a la gente involucrada tenía una sensación familiar, la típica de “estoy metido en un agujero del que sé que no se sale”. Los que trabajamos haciendo en vez de pensando en hacer sabemos perfectamente de qéé hablo. Tenemos ese sexto sentido de “esto no se puede hacer” que a veces nos falla pero cuando da fuerte de verdad, lo sabes.

En mi vida he estado en algunas de esas, pero recuerdo dos, una de ellas hace 15 años donde un lunático pensó que se podía hacer un sistema de domótica en un par de semanas y todos fuimos arrastrados allí. La segunda, de la cual fui además parte de los iluminados que vendían el sueño (y posiblemente el más culpable porque sabía que no era posible), fue en CARTO cuando decidimos que en 6 meses se podría reimplementar el 80% de los construído en años y además añadir más features.

Esto no es un consejo para todo el mundo, pero si volviese atrás, en las dos ocasiones, me hubiese ido de la empresa. Aún sufro consecuencias del peaje que pagué por aquello, en ningún caso me ha merecido la pena, ni he aprendido nada (bueno, aprendí que nunca más lo volverás a hacer) y no guardo ni un solo buen recuerdo. Y lo peor, de largo, arrastré a personas al lodazal.

Afortunadamente teníamos un equipo que supo sacar aquello con unos cuantos meses de trabajo (los que hubiese costado en realidad hacerlo) y mucho esfuerzo. Hay veces que lo de tener un equipo que no te mereces es literal.

En el documental se ve como muchos profesionales abandonan el barco cuando vieron el percal.

Lo triste es que el mundo de software está aún poco profesionalizado y sigue pasando, pero imagino que llegará el día donde los técnicos de este sector seamos capaces de argumentar con algo diferente a rabietas.

Esta semana

Esta semana he terminado mi serie sobre el Data Lake. El Data Lake es algo así como el Fyre festival de los datos, suena perfecto, pero es un trabajo de años, para el que necesitas una cultura de empresa MUY técnica y que incluso así es complicado.

Lo he escrito más pensando en ser una guía para aquellos que estén pensando en centralizar todos los datos que piensen el arco de iglesia que van a montar y si de verdad les da beneficio.

Siempre he pensado que la única forma de aislar lo suficiente a zonas de una empresa es productizar y eso incluye el acceso a los datos. Y dar acceso a Tablau desde fuera de tu equipo/departamento/area a tu base de datos interna no es productizar ni democratizar el acceso a datos, es buscar dependecias externas que limitarán tu avance.

Por aquí la penúltima entrega, las conclusiones y el índice en formato micro libro

Bonus track

Posiblemente ni te interesen los coches ni la mecánica, pero me gustaría que pudiesemos hablar de tecnología con la pasíón que este hombre habla del primer coche tracción delantera que bajó de 9 segundos en el cuarto de milla (un coche de calle potente tarda entre 15 y 17 segundos en hacer 402m)

Tener claro lo que se quiere conseguir, mostrar sin tapujos qué decisiones se tomaron para resolver un problema en vez de darle a la palanca del marketing y tapar lo que realmente es interesante (en el video la limitación del data logger), hablar de los problemas que encontraron por el camino (la suspensión delantera), los problemas que no resolvieron (las roturas de la transmisión en la salida), etc, etc. son las cosas que me gustaría ver en nuestro día a día.

Todo el canal de este señor es brutal si te gustan los coches.

Data lake (y VIII): Conclusiones

Si has llegado hasta aquí y has leído todos los capítulos verás que el Data Lake es el sueño de cualquier empresa media grande. Un sitio centralizado donde se puede consumir de forma uniforme toda la información del sistema.

Bien, es tan soñado que es una utopía si tu empresa no ha arrancado así desde cero (y si tiene cierto éxito, creeme, empezará a haber ramificaciones de los datos por aquello de la agilidad)

Así que si estás planteandote el data lake, data warehouse o sistema centralizado, piensa muy mucho si lo que realmente quieres es que las diferentes áreas de negocio expongan sus datos de una forma lógica.

Cada día más se habla de los microservicios, de dividir las empresas en diferentes áreas para darles agilidad (esto no es nuevo, ya lo decía Ricardo Semler en Maverick), de productizar esas áreas, pero la realidad es que poco se aplica cuando se habla de los datos, donde la centralización es el santo grial, especialmente en empresas donde la estrategia de datos ha sido mover CSV de FTP en FTP y donde básicamente se invierten cientos de millones en mega estructuras que nunca llegan a funcionar porque, ni son ágiles, ni son rápidas, ni son útiles porque se pensó más en la fiscalización que en la disponibilidad de la información y porque hay empresas que saben vender muy bien el dorado cuando el problema que no resuelven es el de las personas.

Hay muchas más estrategías además de centralizar:

Recuerda, tener centralizada la información es el camino, pero el objetivo es hacer que la información esté disponible y a eso se puede llegar por muchos caminos.

Y por último, empieza por la cultura y no por la tecnología, si tus empleados no saben nada de datos (formatos, como se almacenan, distribuyen, consumen…) y no hay unas guías clarísimas que pasen de generación en generación (eso es la cultura, no?) cualquier iniciativa será en vano y terminarán usando la tecnología que se lo ponga más fácil (en este caso en la nube) y lo peor, seguirá habiendo los silos generados para mantener un puesto de trabajo.

Data lake VII: datos derivados

No olvidemos que el objetivo final del data lake es poner a disposición de quien necesite la información de la forma que necesitan consumirla. Es decir, todo lo que he escrito anteiormente no deja de ser grasa, lo importante es poner a disposición la información

Y esto tiene muchos planos, por un lado el que información se necesita, normalmente derivada de la intersección de varias fuentes de datos, y otra el como: a veces se necesita información en tiempo real, otra un sistema analítico para poder hacer descubrimiento, otro se analítica y a veces simplemente se necesita poder exportar a un formato específico (por ejemplo, Excel)

Es decir, tiene que tener la capacidad de transformar y mezclar datos si no que además tiene que soportar cargas de consumo de diverso índole.

Por poner un ejemplo, querríamos disponer de información para servir la analítica de una parte de nuestro negocio en tiempo real (con requerimientos de baja latencia y mucha velocidad) y a su vez tener esos mismos datos disponibles para que un data scientist haga queries muy pesadas para entender y modelar el dataset.

Y claro, que un tipo de carga no afecte a la otra. Y que además este actualizada en tiempo real con nuestro sistema productivo.

Así que, de una y otra forma estamos pidiendo que el data lake sea capaz de ser tan bueno como postgres en carga transaccional, tan bueno como spark para hacer análisis en batch, tan rápido como hbase y siendo capaces de tener capacidades de analítica en tiempo real como kx o Clickhouse.

Y obviamente esto es imposible de tener al mismo tiempo, de ahí que tengamos que replicar los datos.

En general, los casos de uso que debería ser capaz de sustentar son:

  1. Capacidad analítica: es decir, permitir usar BI, herramientas internas, excel o similar para entender los datos

  2. Capacidad analítica++, es decir, permitir casos de uso más avanzados que permitan a gente con más conocimiento técnico usar sus herramientas (jupyter/python, R)

  3. Alimentar sistemas transaccionales. Es decir, una parte del negocio necesita datos de otra parte? el sistema debería ser capaz de poner en su base de datos (mysql por ejemplo) esos datos

  4. Exponer los datos como API. Este es el caso ideal en vez del anterior porque permite a cualquier sistema beber de los datos, independientemente de su naturaleza.

  5. Enviarlos a sistemas variados, S3, FTP, herramientas SaaS…

Y aquí puedes imaginar todo lo que se te ocurra.

Tinybird

Cuando hablamos con alguien con cierta experiencia en el mundillo startup y nos pregunta, después de un rato de conversación “bueno, pero qué queréis conseguir con Tinybird”. Hay muchas posibles respuestas standard en el mundillo en el que nos movemos: “venderla”, “hacer de ella un unicornio” o cualquier empresarial-motivacional.

Pero la cara se les arruga cuando dices: lo que queremos es trabajar juntos de la forma que mejor sabemos, hacer algo que las empresas necesiten, crear un negocio sostenible, con una buena base tecnológica que aporte valor y como resultado ganar dinero. Lo que viene después, como en el 100% de las empresas, nadie lo sabe por mucho que nos empeñemos en buscar fórmulas e indicadores para argumentar lo que básicamente viene a ser una apuesta (un muy bien artículo relacionado sobre la inversión).

Quizá deberíamos entrenar el pitch de vamos a liderar el sector de vaya usted a saber pero no hacen falta grandilocuencias ni adornos artificiales para hacer un buen producto.

Al grano, qué leches hacéis en Tinybird? hacemos dos cosas, un producto y el complemento que casi cualquier producto necesita:

El porqué

Por suerte el sector de la tecnología lleva unos años en la gloria a nadie se le escapa que se puede vivir bien si estás dentro del mundillo y no falta trabajo. Esto es, puedes, ahora mismo, trabajar en una empresa con todas las comodidades, un buen sueldo, sin realmente matarte a trabajar y con retos intelectuales interesantes. Es el escenario soñado.

Y así estaba yo, en un corporate, con ciertos privilegios y con una cómoda jornada de 9 a 5. Quien es el iluminado que me manda a mi dejar ese status quo para meterme en camisas de once varas, no me jodas.

Tiene una explicación sencilla. Hay dos cosas que valoro por encima de los privilegios y el dinero: hacer las cosas como yo quiero y poder trabajar con la gente con la que comparto algo más que oficina. Y esto lo he aprendido a base de confundirme unas cuantas veces y darme cuenta que no todo el mundo está hecho para según que sitios.

Dicho esto, nada tengo en contra de los trabajos 9-5 y ni el corporate (no siempre ha sido así) donde he aprendido muchísimo en un año, sobretodo a respetar ciertas cosas que son difíciles de ver pero que los mantienen vivos y coleando (esto lo dejo para otro post)

Volvamos al qué

Por otro lado tengo en mucha consideración a las personas que aprovechan lo que saben hacer bien, y creo que uno de mis fuertes es hacer sistemas que saben hacer bien la digestión de los datos… puede que llevar 10 años haciendolo tenga que ver. Me mataría dejar de hacer algo con lo que he disfrutado y disfruto.

Qué mejor manera de aprovechar lo que sabemos que haciendo un producto que resuelva algunos de los dolores que hemos pasado durante los últimos años y que vemos todos los días en empresas que trabajan de una forma u otra con datos.

Resolver un problema bien, usando la que consideramos la mejor tecnología para hacerlo, haciendolo con un standard alto de calidad y seriedad, guiado por la necesidad de resolver ciertos problemas y provechando al máximo el conocimiento acumulado gestionando datos en empresas por las que hemos pasado. Y además, hacer todo esto siendo lo más feliz posible y divirtiendose con cada milisegundo que optimizas extrayendo información de los datos. Eso es Tinybird.

Y esto requiere una cantidad de trabajo y esfuerzo que a medida que te haces mayor cuesta hacer. Sí, cuesta trabajo, en mi caso sacrifico horas de otras cosas que me gustan, pero hacer las cosas como crees que hay que hacerlas tiene este tipo de cosas. Sarna con gusto no pica dicen en mi pueblo.

Bola extra: hablando de gente que hace las cosas bien

Al hilo del comentario anterior sobre la gente que sabe hacer las cosas bien y las aprovecha, estoy siguiendo muy de cerca la creación del Instituo Tramontana, especialmente el programa en dirección de producto que imparten dos buenos amigos.

Pero no es solo el contenido del programa, es todo lo que está alrededor del curso, el espacio la solemnidad del programa, las referencias a libros y contenidos con tantos años como calidad (uno de mis propósitos de este año era no leer libros con menos de 30 años, que como todo propósito, he incumplido) y la dedicación con la que están preparando todo. Os recomiendo seguir la lista de correo de Javier, el directo del instituto, donde va contando algunas cosas relacionadas y otras que no, pero que dan contexto.

Las Matematicas

Tengo un recuerdo agridulce de los problemas de matemáticas de la escuela: todo lo sencillo que parecía cuando veías a la profesora resolverlo paso a paso pasaba a ser un mar de dudas cuando te enfrentabas al problema tu solo.

Añadía más frustración el pensar que lo habías entendido perfectamente.

Lo que no sabias era que la profesora había hecho miles de veces problemas como ese, tanto que podía hacerlos mientras los explicaba.

Cuando leo un blogpost sobre cómo la empresa X resolvió Y, ya sea usando microservicios, tal base de datos o cuál metodología, y que además el problema se igual parecido al mío, me pregunto si no será mi profesora de matemáticas convertida en desarrolladora. Me pregunto si no será mucho más complicado y no habrán pasado miles de veces por ahí. Y entonces me pregunto si yo tengo tiempo de pasar miles de veces por ahí.

Por otro lado no hay cosa más divertida que enfrentarte a algo nuevo, es realmente la única forma de entender algo que ya has entendido.

La charla de la semana

En este mundo donde las conferencias se han covertido en en fin (y no como resultado de hacerlo bien) para conseguir leads, en donde la calidad brilla por su ausencia, donde un título “catchy” vale más que plasmar años de trabajo en una charla, da gusto encontrarse con maravillas como esta. Y me ha gustado por varios motivos:

No hay mes que no piense en organizar una pequeña conferencia donde la gente venga a contar la verdad del día a día sin miedos, a explicar cómo hacen esto o aquello, o como resolvieron lo de más allá usando el hack más absurdo.

John Carmack

No es noticia que Carmack es uno de mis programadores favoritos. Gracias a él aprendí muchísimo leyendo el código de Quake (especialmente el 2), escuchando sus maravillosas master class en las quakecon y leyendo maravillas como esta, cuando se fue una semana aislado a aprender machine learning. La forma en la que “locuta” me hipnotiza.

Hace pocos días le han hecho una entrevista en un podcast bastante conocido (que no conocía). La entrevista es tan larga como interesante (puedes encontrar resúmenes por ahí), así que da para hablar de bastantes temas: VR, redes sociales y sus problemas, el tema sobre cuantas horas hay que trabajar, coches, videojuegos… en todos ellos su visión es muy muy sensata aunque creo que el hecho de trabajar en Oculus (comprada por facebook) le hace tener una posición un poco sesgada sobre lo que la cúpula de facebook piensa.

Dejando a un lado esa posición sesgada y que está maravillado con su Tesla… hay dos temas que me han llamado la atención poderosamente:

El primero es cuando habla sobre la cantidad de horas que trabaja. Comenta que él solo puede ser productivo 13 horas al día… últimamente ha habido una gran cantidad de comentarios sobre este tema dando recomendaciones sobre cuanto trabajar. En mi vida ha habido periodos donde he trabajado 10-12 horas al día y no los cambiaría por nada. No es sostenible ni para todo el mundo, obviamente, y cada periodo de la vida tiene diferentes prioridades, pero en mi opinión es complicado ser muy bueno en algo si no inviertes una buena cantidad de horas. De ahí que esté un poco de acuerdo con Carmack aquí sobre que cada uno elija libremente las horas que puede o no trabajar (sabiendo, eso sí, que hay vida necesaria más allá que el editor de código)

El segundo, y más importante, es cuando habla de la velocidad de computación

Las máquinas están empezando a ser más lentas, no en absoluto, pero la velocidad a la que la velocidad crece ha bajado dramáticamente. Y el punto está en que, según carmack, los móviles están llegando al límite de lo que pueden dar.

Como derivada, y esta es la parte más llamativa, habla de un cambio cultural, tenemos que empezar a volver a pensar en el performance. Y no es el único, cada semana veo varios artículos sobre como la web está a rebosar de código que hace que vaya lento en todo lo que no sean móviles de última generación. La gente ya no sabe que pasa debajo del código que hace (React, te estoy mirando a ti) y en general se tiende a pensar que con levantar unas cuantas máquinas más en AWS resuelve todos los problemas. Aquí una charla de otro de mis favoritos, hablando precisamente de como el hecho de que los desarrolladores actuales no tengamos ni puñetera idea de lo que pasa por debajo es algo muy muy malo en un futuro próximo (un poco apocalítico, pero bueno)

No puedo estar más agradecido de haber empezado mi carrera profesional haciendo videojuegos, donde tener que refrescar millones de pixeles 60 veces por segundo hacía que el “performance” fuese un ciudadano de primera.

Hablaré más sobre este tema en futuros post

Qué he estado escribiendo esta semana

Este mes de agosto he escrito bastante pero he publicado muy poco, cosas de las vacaciones y que por otro lado dejo madurar los posts unos días para ver si pasan el test de la lectura después de una semana.He avanzado con mi serie de post sobre el data lake, en esta entrega la trazabilidad

Estoy escribiendo esta serie con dos objetivos: 1) Que alguien que se pregunte qué leches es un “data lake” lo sepa 2) Demostrar que un daka lake es una panacea y que no deberías hacer algo así.

En qué estoy trabajando

Casi todas las bases de datos tienen sistemas para planificar como van a ejecutar una query en base a unas estadísticas sobre los datos. Suelen ser sistemas complejísimos y a veces tienes que saber como funcionan para optimizar bien las queries.

Clickhouse, mi base de datos favorita, no tiene un planificador (tiene algo muy simple, que dicho sea de paso simplifica todo el diseño), no obstante las queries se pueden ejecutar con diferentes parámetros. Estoy usando una aproximación diferente: en vez de calcular estadísticas de los datos y ver cual es el mejor plan, estoy ejecutando los diferentes tipos de queries con diferentes parámetros y entrenando un modelo de ML para luego saber cual es el mejor plan dados unos parámetros. De momento el modelo predice con exactitud el tiempo de ejecución (lo que me ha sorprendido gratamente).

El objetivo es integrarlo en Tinybird para los endpoints que tengas publicados. Publicaré los resultados en el blog de Tinybird

Hay aproximaciónes para usar ML en bases de datos, aquí un articulo brutal de como usar un modelo para sustituir a los índices tradicionales.

Extra lap

Si vas a leer algún link de esta lista, que sea este post de Feli, “tengo cáncer

Data lake VI: trazabilidad

Hay dos momentos en los cuales quieres saber lo que está pasando en tu sistema: cuando lo estás integrando y sobretodo, cuando pasa algo malo.

Así que quieres saber qué, cuándo, quién y cómo.

Que ha pasado: alguien ha accedido a un dato, alguien ha metido datos, borrado, cambiado…

Cuándo se ha hecho lo anterior

Quién, que persona o que bot (y quién es responsable de ese voy)

Y cómo: por API, por web…

Pero no queda ahí, además de guardar toda esa información tienes que ser capaz de consultarla. Quién no se ha encontrado con 300gb de logs que hay que investigar cuando hay un problema.

Y ojo, no solo para los datos, también para los metadatos. Por ejemplo, cuando se le dio permiso de escritura a fulanito?

Tan fácil de escribir, tan difícil de implementar bien.

Brain Power

A veces creo que tenemos una capacidad de concentración finita y que cuando llegas al límite tu cerebro dice basta. Esta semana creo que he sufrido una pájara cerebral después de 3 días diseñando un sistema de analítica en tiempo real (con cientos de Gb/s y respuestas por debajo de los 150ms). Ya sabes, esos días en los que te alegras de haber caído en esta profesión y que por otro lado te preguntas si no podrías haber montado algo más sencillo y vivir tranquilamente 🤷🏼‍♂️

Al tema, esta semana he hablado de:

Cloud computing

Hace no muchos años las personas en el mundo del desarrollo tenía que pelearse para conseguir ejecutar su software en máquinas muy limitadas de memoria. Hoy con máquinas 1000 veces más potentes en todos los aspectos, necesitamos cientos de ellas para ejecutar los servicios más triviales (en pro de una velocidad de desarrollo que no es tal). Y lo peor, no hay una buena solución.

Mi apuesta personal es que la mayoría de servicios que usamos (fuera de los google, amazon, facebook…) podrían correr sin problema en una sola máquina si hubiese un poco de inteligencia en como transferimos y procesamos los datos.

Aquí va el post

Al hilo de esto, pintesrest tiene 450 máquinas solo para su parte analítica, un total de $125M/año (imagino que contando todos sus servicios).

User testing

En tinybird hemos hecho unos tests con usuarios para entender como otras personas usan y entienden nuestro producto y hemos compartido unos números y aprendizajes en el blog

Una de las cosas que he vivido cuando tienes inversión de capital riesgo es que, como tienes dinero, hay ciertas necesidades cubiertas. Cuando esto pasa, dejas de entender cosas básicas, como saber quien te tiene que dar de comer. De ahí que una de las cosas que hemos decidido al empezar tinybird es hacer consultoría, que es el mejor user testing posible.

Conducción autónoma

A mi me gusta conducir pero es obvio que el futuro no va por ahí (y me alegro en parte). Hay una competición de coches radio control autoconducidos en, adivina, estados unidos, donde hacen carreras por un pequeño circuito. Yo intenté empezar aquí un grupo similar, pero no cuajó (los grupos de react tienen más éxito)

Sin embargo, es super interesante ver como mejoran en cada carrera que organizan y ya están al nivel de un conductor humano. Aquí tienes los resultados y los trucos que usan,

Cloud Computing

Hace ya unos años se empezó a hablar de cloud computing.

Para los nativos digitales poder tener máquinas bajo demanda es lo lógico. Para empresas donde los desarrolladores tenían que decir 6 meses antes que máquinas iban a necesitar para poder pedirlas, instalarlas y demás era la panacea.

De hecho, una de las cosas que más te choca cuando empiezas a trabajar con el corporate como proveedor de software es que te piden que les digas el aprovisionamiento necesario para X usuarios. Que dicho de paso, no tienes ni idea porque tienes la falsa seguridad de que tu software escala añadiendo máquinas y bueno, porque saber medir y ajustar la carga requiere de un control absoluto de la mayoría del software que usas y/o tener experiencia con algo que te aplaste (yo aprendí por fuerza bruta gracias a Google y el WSJ)

Sin embargo la nube se vendió como un sitio maravilloso dónde tú no tenías que preocuparte de nada, tu software escalaba solo. Típico overselling que cualquier mid manager se podía tragar. Con lo fácil que hubiese sido dejarlo en “tu infrastructura bajo demanda, en menos de 1 minuto”. Hoy muchas empresas desarrollan como si tuvieran esa capacidad y están “limitadas” por un datacenter con poca capacidad de cambio. O por el dinero, porque levantar máquinas es fácil, pero luego nos encontramos con facturas de 20k/mes.

La realidad del asunto es que empresas como Amazon, Google pueden desarrollar software distribuido resiliente que puede correr en hardware barato que muere cada dos por tres. Y pueden desarrollarlo porque tienen gente muy buena en ese área, que sabe como hacer software distribuído e invierten años en hacer que funcione bien. Pero la mayoría de desarrolladores al uso nos quedamos en lo que nos da el framework (4 ó 5 niveles por encima de entender lo que significa una split de red), todos veníamos de tener hardware muy bueno (y caro).

La derivada de eso es que tu software sigue pensado para correr en cosas que no falle pero usando servicios AWS que si están pensados para correr en cloud. El paradigma de hacer software par a la nube se basa no en seguir un paradigma (que como digo, es muy complicado y caro) si no en usar unos servicios que nos proveen (a precio de oro). Así que es normal que todos los proveedores apuesten por microservicios, kubernetes y sistemas complejos donde necesitas apalancarte en su tecnología. Esto no es necesariamente malo, pero no todo el mundo lo necesita (y puede admitir esa complejidad).

La jodido de esto es que no hace mucho hablábamos de “el grid”, dónde el sistema operativo se encargaba de gestionar la complejidad por ti. De hecho la unión Europea se gastó una millonada en proyectos de investigación, subvenciones que lógicamente trincaron los de siempre. Puedes ver el proyecto xtreemos aquí.

Así que en vez de trabajar en software que sea capaz de paralelizar trabajamos en integraciones con servicios. Lo triste es que lo más parecido a un paradigma cloud son las famosas aws lambda/google run.

Necesitamos otro Torvalds y gente con un poco de cabeza que entienda los problemas que están por venir: Jonathan Blow - Preventing the Collapse of Civilization

Data Lake, parte V: autorización

Tienes todos los datos de tu empresa en un solo sitio. Nadie en su sano juicio permitiría acceder a todos los usuarios a todos los datos. Esto obviamente no aplica tanto a una pequeña empresa, aquí con dar acceso de solo lectura a una réplica de la base de datos de producción [1] para que la herramienta de BI de turno pueda coger datos es más que suficiente. Eso sí, no llames a esto “democratizar el acceso a datos”, el término sería “anarquizar el acceso a datos”

Porque hoy hay 30 personas en tu organización pero mañana hay 120 y luego 119… me sigues no? Esta es una razón para dejar que ciertas personas vean solo ciertos datos, pero hay otras, por ejemplo simplificar la vida de la gente.

De ahí que tengas que tener un control de acceso (autentificación). Esto es tan viejo cómo que la cueva Alibaba ya tenían un password

Pero ahora podemos hacer algo mejor que tener una sola puerta para la cueva, podemos tener sistemas de autorización robustos:

En este último punto es donde se suele pinchar si la empresa tiene cierto recorrido: es complicado entender que hay actores no humanos, que, de hecho, son los más importantes, porque como dice Vicki Boykis, los humanos estamos para dar significado a los datos, para procesarlos ya lo hacen mejor las máquinas.

[1] Evita como puedas dar acceso a la base de datos de producción, por mucha prisa que tengas.

Ci

Time To Fix

Una metrica fundamental (*) que cualquier equipo de desarrollo/producto (bueno, en realidad toda la empresa debería estar involucrada aquí) debe medir y mejorar es el tiempo desde que un cliente tiene un problema hasta que ese mismo cliente deja de tenerlo.

Parece una metrica tonta, es facilísima de medir, basta con tener un tracker de issues e ir cambiando los estados a medida que la fases (reporte, evaluación, fix, deploy, test, close). Sí, esto es el peñazo universal, pero también lo era ponerte el cinturón de seguridad al montarte en el coche ahora no puedes avanzar un metro sin él puesto.

“deployear”

Una de esas fases es el deploy, es decir desde que tu código está en el control de versiones, hasta que llega a estar en producción.

Nadie ya discute que ese es un buen procedimiento, que debe estar automatizado y responder a cambios en el repositorio.

Vale, ahora imaginad que retrocedemos 20 años en la época en la que había un servidor FTP donde unos ficheros PHP era ejecutados por apache. O incluso unos scripts corriendo por CGI (las lambdas de hace unos años, para los milenials)

Imaginaos editar directamente esos ficheros en producción, es decir, cuando guardas en el editor la siguiente request ya usaría el nuevo código.

Nos hemos acostumbrado a cosas lentas

Obviamente hay muchas razones para no hacer esto, pero así se hacia hace años y es el en lo que tienes que pensar cuando tu deploy tarda 30 minutos: el baseline son unos milisegundos, así que todo lo lejos que estés de milisegundos lo estás haciendo peor que hace 25 años.

Digo obviamente pero yo no tengo tan claro que las herramientas actuales de desarrolladores no sean “caballos más rápidos” y no coches como diría Ford. Lo mejor que he visto últimamente en esta línea es esto y glitch, que está empezando de juguete pero “ojo lluvia” que viene de gente que sabe como hacer producto web. Pero este tema da para otro post.

Nos hemos acostumbrado a que las cosas vayan lentas a cambio de unas promesas que, en muchos casos, no son ni media verdad.

(*) Si tienes un equipo de desarrollo mediano (+10) la métrica TTF (time to fix) es un driver buenísimo para mejorar la calidad del desarrollo. Y además si eres CTO te sirve como métrica para poner en el excel para los inversores (que siempre es un peñazo encontrar buenas métricas)

Pico 8

Había visto ya hace un tiempo gente publicando imágenes con el hashtag #pico8 y me habían llamado la atención pero nunca me he parado a ver de qué iba y no sé si es nostalgia pero estoy enganchado.

Básicamente es una consola virtual, con sus cartuchos virtuales con un par de peculiaridades: el developer es first class citizen y las restricciones son muchas, por ejemplo, tienes una paleta de fija de 16 colores, el tamaño de la pantalla es 128x128px (hay favicons más grandes) y un máximo de tamaño de juego de 64kb. Solo hay que echar un ojo al cheatsheet

Y esto hace que como producto sea espectacular. Tiene todo lo que necesitas para hacer un juego (lógica, sprites, mapas, efectos de sonido y música (*)) en el mismo sitio, te permite hacer virguerías, pero te las restricciones te obligan a hacer las cosas super sencillas.

Nada de complicaciones, con esos recursos tienes todo lo necesario, eso sí, crear, modificar y usar esos recursos en el juego es muy muy fácil, así que las limitaciones se convierten en una ventaja.

Cómo plus tiene un halo retro y una filosofía del software noventero preinternet que hace echar de menos la época de cuando el software lo hacía gente en otra liga.

(*) Si te interesa la generación de audio procedural escribí un artículo hace unos 14 años sobre como generar audio en demos de 4kb.

Joinable Api

TLDR: nowadays any software service depends on others. The problem is your data ends up being distributed and there is no easy way to join those different sources easily. I’m proposing a “joinable API” to fix that problem.

Data lock-in

We have been talking about the vendor lock-in for years, where once you start using a provider it’s nearly impossible to move to a different one. I think the software world is like that no matter the software you use: once your software is running on production changing it is a really expensive and painful task.

Before the explosion of SaaS providers we had data exporting tools so you could more or less get your data in a standard format and import to another system. Today that’s not totally true: try to get all “your data” from your google analytics account. Don’t worry, those providers have tools that can access your data easily.

Hundred of services

10 years ago was easy to see a monolithic services running on just one big machine with everything needed in there (user management, accounting, the service itself) today you start a company and the one week later your software is talking to several services through HTTP APIs.

That’s good, you spend your time in the thing you provide more value instead of doing billing code.

Give me some stats

Eventually, someone will ask a question like “hey, how many users do we have in our XXXX tier, have signed up 3 times during the last month and also have ….”

So you either 1) use a platform that collects everything or 2) a one that fetches data from all those services and put data in a place you can query. in any case, querying data from a third party services is a pain. Here is the point where a lot of scrapping and “CSV file transfer” horror stories start.

Joinable API

Most of those operations are what we call joins. It’s easy to do when all the data is in the same place but hard to do in a distributed system.

So how do we keep those services and at the same time the possibility of using our data? why don’t we request to our service providers to have a Joinable API apart of full, easy to use and documented data dumps and their regular service API (more on this in this excellent talk)

Tech solution

Let’s imagine you have a regular OLTP database like Postgres, it’d be nice to be able to do:

SELECT * FROM MyTable 
JOIN Service('billingservice.com', 'transactions')
ON ... 
WHERE date = yesterday() ...

fetching remote data is already supported by Postgres using FDW (and all databases have a way to fetch remote data) but the problem is getting the data from the service.

The service would need to provide:

This is what most of the distributed databases do, it’s not rocket science, a common well-tested pattern that every single service should expose so you don’t have data lock-in.

Data lake parte IV, los cambios

El modelo de datos cambia sí o sí, básicamente porque modelan la vida real y la vida real cambia. Mucho.

Queremos que las cosas no cambien

Todas las bases de datos series tienen mecanismos para cambiar la forma de los datos. Es muy simple añadir una columna, cambiar el tipo o el nombre. Hay algunas incluso que el cambio es la constante como las orientadas a documento.

Dado que van a cambiar queremos:

Esto es más o menos trivial a nivel de gestión, lo complicado es saber cuando los datos han cambiado. Parece fácil, pero no lo es, a menudo los desarrolladores cambiamos el modelo de datos, el interfaz del API sin tener en cuenta todos los sistemas afectados.

Los tipos de cambios

Hay dos cambios fundamentales (bueno, seguramente más, pero estos son los peores) que se pueden producir en los datos:

En ambos casos debe haber una diferencia clara.

El interfaz común

La clave del asunto es no afectar a los sistemas que dependen de estos datos (si es posible). Si por ejemplo, se añade una nueva columna o atributo, es fácil hacer que los sistemas que beben información sean compatibles.

Si pasamos de millas a kilómetros es fácil que la mayoría de sistemas se vuelan locos. Tenemos dos opciones, o cambiar todos los sistemas que dependen de mis datos o expongo mis datos a través de un API en el que pueda multiplicar por 0.62 los datos en millas y por 1.0 los de kilómetros.

Data Lake, parte III: El catálogo

Además de poder importar datos de forma sencilla hay otro tema fundamental que es saber qué datos has importado.

No me refiero solo a saber “el día 25 importamos estos datos” si no a saber de qué van esos datos:

Obviamente son todos los que están pero no están todos los que son. De hecho hay un tema peliagudo que es el control de los cambios, pero eso lo vamos a dejar para la parte IV.

Pero esto no es todo. Aunque tengamos catalogados con absoluta perfección no solo tenemos los datos que entran, si no los que salen.

No tiene sentido tener un data lake sin poder explorar esos datos. Y lo habitual no es consultar los datos de entrada si no más bien datos derivados que muy posiblemente vengan de un JOIN (JOIN de SQL para los que vengan de usar Mongo) con otras 3 ó 4 fuentes de datos (alguna posiblemente externa). De hecho es casi más importante este catálogo como el de los datos de entrada. Pero de eso hablaré en la parte VII.