14/03/2022

Historias de las trincheras. Una aplicación exitosa

Armas al Hombro. Charles Chaplin

Permítanme antes de ir al hueso de nuestro tema una pequeña historia

Dígame si le parece familiar el siguiente relato ficticio. Se empieza a trabajar en un proyecto de software. Siguiendo las buenas prácticas de la época se intenta separar las capas de la aplicación en modelos, vistas y controladores. Se decide usar la versión más moderna del lenguaje de moda, y la última versión disponible de su framework más reconocido el cual viene integrado con su propio ORM. Se decide además usar el motor de base de datos XSQL como capa de persistencia de datos. La aplicación es un éxito. Cada vez más clientes contratan sus servicios y el número de estos comienza a crecer exponencialmente, hasta contarse algunos miles de usuarios; y después de algunos años hasta empiezan a haber planes de internacionalización.

En ese momento, las peticiones de soporte empiezan a crecer, y un buen número de estas trata sobre la velocidad y tiempos de respuesta de la aplicación. La primera idea es actualizar los componentes del sistema a versiones recientes, pero ¡Oh, sorpresa! el componente que se encarga de manejar xml tiene como dependencia un paquete descontinuado, y el ORM integrado depende del paquete que maneja xml. Como imaginará, si no actualiza el ORM no puede actualizar el framework que lo integra, y las nuevas versiones del lenguage soportan el framework desde la versión 3, cuando su aplicación se basa en la versión 2

La actualización de las dependencias de software no es posible.

Surge entonces la idea de montar la aplicación en máquinas más poderosas, si no podemos actualizar el software, actualicemos el hardware. Entonces contratamos máquinas en el proveedor de servicios cloud mas conveniente. También se empieza a escuchar sobre un nuevo trending en la industria del software, los microservicios. Si descomponemos la aplicación en un conjunto de pequeñas utilidades que realizan un solo trabajo, lo realizan bien, y gatillamos su inicio con llamadas a api, mejoraran los tiempos de respuesta por la simple razón de que puedo levantar muchas máquinas en nuestro proveedor cloud con los microservicios mas demandados.

Todo va viento en popa, los tiempos de respuesta mejoran ostensiblemente y la internacionalización es un hecho. Sin embargo, la moneda del nuevo país donde tenemos clientes posee una submoneda; centavos, centimos, peniques o como se llame. Es decir, los montos que la aplicación debe manejar son números con decimales. La moneda del país original no contaba con algo parecido y todos los cálculos monetarios eran redondeados a números sin decimales.

Rápidamente se desarrolla una corrección, que consiste en cambiar el redondeo desde no conservar decimales a mantener un número arbitrario de estos. Esta corrección hace los cálculos monetarios usando el tipo de datos de números de coma flotante, los cuales no pueden representar con exactitud números decimales debido a la impĺementación de su aritmética, por lo que cuando se ven involucradas cantidades muy grandes, aparecen diferencias inaceptables en los monto calculados.

Usar un tipo de dato especial, del tipo BigDecimal o Currency esta fuera de discusión porque prácticamente significa reescribir la aplicación.

Por otro lado, como seguimos vendiendo los servicios del sistema, los clientes siguen multiplicándose, volviendo a aumentar los tiempos de respuesta. En esos momentos, un miembro del equipo propone migrar el manejo de la capa de persistencia de datos a ZSQL o Y-NOSQL cuyos benchmarks demuestran una velocidad con la que el viejo y querido XSQL solo puede soñar. Pero, tras hacer los experimentos necesarios, vemos con horror que el ORM del framework no soporta ninguna de estas nuevas alternativas.

A estas alturas, uno como programador no puede hacer mucho más que resistir en las trincheras. Después de todo hay que poner pan en la mesa y se nos paga por escribir código, bugfixes y nuevas features, no por ventilar nuestras preocupaciones. Tampoco pueden hacer mucho líderes de equipo ni product owners, pues deben responder ante críterios comerciales. No, en esta situación no hay nada mas que hacer que resistir en el frente sacando correcciones, con la esperanza de alcanzar a ver el armisticio que marque el cese al fuego. Y a veces cae fuego pesado desde todos los frentes.

0 comentarios:

Publicar un comentario