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.
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.
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.
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.
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.
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 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(*):
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
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 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
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.