Mirando a Redis: ¿de verdad somos desarrolladores que inventan?

Al mirar el ecosistema de Redis, vuelvo a preguntarme si realmente puedo decir con orgullo que soy un desarrollador que inventa.

El nacimiento del almacenamiento Key-Value

• Con la llegada de la era Web 2.0 después de los años 2000, las empresas de servicios web se enfrentaron a la necesidad de soportar una enorme cantidad de usuarios
• Para manejar ese tráfico masivo, se volvió necesario contar no con servidores grandes y costosos, sino con sistemas distribuidos a gran escala, pequeños pero baratos
• Por suerte, la mayoría de las estructuras de datos eran simples (ej. obtener la información de userid = 1234)
• Usar una base de datos relacional (RDBMS) era demasiado pesado, caro y complejo
• Aparece el teorema CAP
• Entonces, aunque hubiera que sacrificar consistencia, bastaba con asegurar disponibilidad y velocidad
• Así nació una base de datos simple que recibe una key y devuelve un value (Memcached-2003, Amazon Dynamo-2007)

El nacimiento de Redis

• En Italia, la cuna de la pasta, un desarrollador llamado Salvatore Sanfilippo operaba una startup llamada LLOOGG (sí, la palabra Log está escrita con doble letra)
• LLOOGG ofrecía un servicio de seguimiento en tiempo real de visitantes de sitios web
• Era pequeña, pero sí tenía usuarios reales
• En ese entonces, el análisis en tiempo real era una tarea bastante difícil
• Los datos empezaron a acumularse → el RDBMS existente se volvió cada vez más lento → ya no había capacidad de respuesta en tiempo real
• Para responder en tiempo real había que usar memoria → Memcached en ese momento solo soportaba GET y PUT simples en formato string
• ¿Se necesitaban funciones de diccionario un poco más avanzadas como INCR, DECR y LIST, y no existía una DB así? → chingada madre, entonces la hago yo
• Así nació una versión inicial que funcionaba sobre un servidor TCP ultrabásico (sin funciones avanzadas como clúster, AOF o replicación)

La evolución de Redis

• Redis nació no como caché, sino como un almacén de estructuras de datos para procesamiento en tiempo real
• Pero la gente empezó a usarlo como caché
• Las exigencias de estructuras de datos más allá del caché por parte de gigantes ya establecidos (Facebook, Twitter, GitHub, Stack Overflow, etc.) fueron creciendo
• Empezó a adoptarse gradualmente para pequeñas funciones como almacenamiento de sesiones, gestión de tokens de inicio de sesión, contadores en tiempo real, sistemas de ranking y número de likes
• Distintas funciones necesarias y estructuras de datos se fueron agregando de forma evolutiva (Sorted Set, HASH, Cluster, persistencia...)
• Terminó convirtiéndose en una plataforma flexible de procesamiento de datos

Comunidad, UX y la filosofía del desarrollador

• Redis se basa en la filosofía de que puede tener muchas funciones, pero no debe ser complicado
• La documentación oficial ofrece ejemplos ejecutables al instante basados en CLI y explicaciones claras del comportamiento
• Con comandos intuitivos (SET, GET, LPUSH, ZADD, HGETALL, etc.), basta con echar un vistazo rápido a la documentación oficial para captar enseguida para qué sirve cada uno
• Esta intuición va más allá de simplemente ser conveniente: cumple el papel de reducir la barrera psicológica hacia la herramienta y aumentar la productividad del desarrollador
• La versatilidad que surge de esta estructura beneficia a usuarios, proveedores de nube y contribuidores de código abierto por igual
• En un ecosistema compuesto por beneficios mutuos, Redis se consolidó como el estándar de facto de las DB en memoria mediante una elección no impuesta

Mirando el ecosistema de Redis

• Redis comenzó como un medio para implementar una idea quizá común: el análisis en tiempo real de visitantes
• Superó los límites del enfoque existente llamado SQL (lento y caro) con una aproximación nueva
• No fue una optimización de reglas existentes como aprovechar contactos de la industria, exprimir proveedores, ajustar hardware o limitar el uso
• Creó una regla nueva: convertir la memoria en un elemento central de la DB
• Para diseñar directamente una herramienta, proponer un flujo que antes no existía y lograr que el mundo entero lo adopte, es importante contar con conocimientos fundamentales para la aplicación
• Incluso Amazon Dynamo, diseñado para resolver el problema del almacenamiento del carrito de compras, requirió aplicar conocimientos complejos de sistemas distribuidos
• Cuando algo se convierte en estándar de la industria por elección voluntaria de todos, se genera un enorme valor agregado y empleo
• Basta ver a los especialistas en Redis, la infraestructura de hardware, los contenidos de aprendizaje, los servicios administrados (AWS, Azure) y las soluciones especializadas (Redis Enterprise) para entenderlo
• Nada de esto fue creado por políticas gubernamentales o leyes del tipo “salvar tal o cual industria” o discursos sobre pymes

Debemos preguntarnos si todavía vivimos con una mentalidad propia de la era manufacturera, aunque por fuera parezcamos un país desarrollado, y si quizá estamos confundiendo al desarrollador con un trabajador de la industria de servicios del conocimiento.

• Si podemos demostrar con resultados por qué la tecnología básica (ej. algoritmos) es importante
• Si existe una cultura de desarrolladores y un sistema educativo capaz de crear herramientas para resolver problemas
• Todos dicen que hay que fomentar una cultura que tolere el fracaso, pero ¿yo mismo no me enojo o insulto los errores de otros?
• Si realmente entendemos el verdadero valor agregado de la industria de servicios del conocimiento y podemos empujarlo con persistencia

Vuelvo a recordarme que un verdadero desarrollador no es simplemente alguien que sabe usar herramientas, sino alguien que, aunque sean modestas, diseña por sí mismo las herramientas que necesita, y las hace fáciles de usar para otros, de modo que pueda expandir el ecosistema y generar valor agregado.

[roxie]

Siento que soy un fraude :(

[iolothebard]

La invención de la utilidad…