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.
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.
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:
Capacidad analítica: es decir, permitir usar BI, herramientas internas, excel o similar para entender los datos
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)
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
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.
Enviarlos a sistemas variados, S3, FTP, herramientas SaaS…
Y aquí puedes imaginar todo lo que se te ocurra.