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
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.
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.
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.
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)