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.
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.
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
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í.
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.
Si vas a leer algún link de esta lista, que sea este post de Feli, “tengo cáncer”
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.
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:
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).
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.
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,
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