Cortando la cola del pavo

Published on Author lopez

Había una vez una familia que se reunía una vez por año, para celebrar juntos. La dueña de casa solía cocinar al horno un pavo relleno. Una receta que habia pasado de generación a generación, por vía oral, especificaba qué colocarle, cuánto tiempo cocinarlo, cómo preparar el relleno. Pero había algo que hacía siempre: cortarle la cola al pavo. Alguien preguntó: “¿Por qué hay que cortarle la cola al pavo? ¿Por qué está esa instrucción en la receta?”. Sorprendentemente, la cocinera sólo atinó a responder: “No sé, así lo hacía mi mamá, así me lo enseñó”. Fueron a preguntarle a la madre: “No sé, a mí también me lo enseñó así mi mamá”. Le preguntaron a la abuela: “Yo tampocó sé, así me lo enseñó mi mamá, en mi infancia”. Y al final, llegaron a la bisabuela: “Bueno, cuando vivíamos en Europa, en una casita en el campo, el pavo no entraba en el horno, y teníamos que cortarle la cola”.

¿Cuántas veces nos pasa, en nuestras actividades, profesionales o no, “cortar la cola al pavo”, sin notar que las fuerzas que llevaban a esa conducta ya desaparecieron?

Para poner un poco de contexto, veamos un ejemplo en el desarrollo de software. Cuando aparecieron las primeras microcomputadores, no había discos duros, solamente discos flexibles. Y muchas veces, la computadora sólo tenía disponible una dispositivo de discos flexibles (la “diskettera”). Recuerdo un sistema de sueldos y jornales, a principio de los ochenta. A fin de año había que calcular por empleado cuánto tenía que abonarse de aguinaldo. La ley había cambiado: ya no era un monto asociado al último sueldo, sino lo que había cobrado por cada cada mes. No había forma que un disco flexible tuviera toda esa información. Así que el operador, para calcular el aguinaldo, tenía que introducir y retirar uno por uno los discos de las liquidaciones mensuales. Eran las limitaciones de esos tiempos.

Y en minicomputadores, los discos duros no eran el último lugar de resguardo. Se usaban cintas, para sacar copias de los programas y los datos.

Desde los “mainframes” fue llegando la implementación de bases de datos (relaciones, jerárquicas, en red, aunque sólo sobrevivieron las primeras; la nueva “onda” de NoSQL no es tan nueva :-). Y la próximas implementaciones de los sistemas en computadores personales pasaron a usar bases de datos, en general relacionales.

Y siguió el progreso. Pero algo quedó de resabio, de reliquia, algo como “cortar la cola del pavo”: hoy se piensa en tener todo en la base de datos. Pero hoy tenemos gran cantidad de memoria disponible. Muchas veces, podemos tener nuestro dominio TOTALMENTE en memoria, y muchos casos de uso son de “muchas lecturas, escrituras esporádicas”. Pero en vez de aprovechar directamente la memoria (vean que puse TODO el dominio en memoria, no estoy hablando de “cache” selectivo), todavía se inicia el desarrollo de un sistema viendo el esquema de base de datos.

No digo que sea aplicable a todos los casos, pero en muchos sistemas, la base de datos (o el disco, al final), es la “nueva cinta”: la forma de resolver la persistencia. Pero la operación bien podría hacerse completamente en memoria. Aún en memoria distribuida. Por ejemplo, en Facebook, en su implementación, todo es un objeto (una persona, una relación, un mensaje, una foto, …), y se almacena en un sistema que llaman TAO (de The Abstract Object). Usan MySql (muchas bases) sólo para persistencia. La operación la resuelvan en memoria: TAO corre en multitud de máquinas distribuidas en varios data center, y usa MySQL principalmente para persistencia, y replicación, apenas para el negocio.

No hace falta ser Facebook para aprovecharse de “primero la memoria”, en vez de “hay que cortar la cola del pavo, hay que usar base de datos relacionales”. En un sistema que estuve examinando, con un caso de “muchas lecturas, pocas escrituras”, pude implementar el caso de uso principal en memoria, quedando CUATROCIENTAS VECES más rápido (no digo 400 por ciento, digo 400 VECES). Y otro proceso, que tardaba en el orden de las ocho horas, paso a ejecutarse en minutos, adoptando un modelo en memoria.

Y ése es sólo un ejemplo. Ahora, agua para mi molino:

Test-Driven Development (TDD), al empujarme, como flujo de trabajo, hacia la implementación más simple, casi como que me impide complicarme con soluciones que níngún caso de uso pidió. Sólo se adopta una base de datos relacional, o un NoSQL, cuando el caso de uso lo pide. Y siguiendo TDD he notado que esa decisión, que puede ser diferida, aún cuando se tome, se puede cambiar en el futuro. Por eso soy escéptico cuando alguien quiere plantear cuáles herramientas usar ANTES DE PASAR por los casos de uso.

Con el caso de uso “nuevo horno más grande” desde el principio, nunca se llega a implementar “cortar la cola del pavo”.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez