FinOps — El PDF que costó 1,500 dólares al mes por un diseño sin supervisión

Cuando escalar la infraestructura es más fácil que arreglar el diseño. En una cuenta en Perú identificamos la necesidad de construir PDFs a partir de los datos que se generaban en cada solicitud. La decisión de diseño fue usar una máquina virtual y una librería que construía el PDF a partir de HTML — con una particularidad que nadie capturó a tiempo: cada llamada a esa API creaba una instancia de Chrome, y esa instancia nunca se destruía.

El costo de tapar el síntoma con más cómputo

El consumo de memoria crecía con cada solicitud hasta agotar el recurso disponible. A eso se sumó que nunca se hicieron pruebas de carga. Cuando salió a producción — y peor, cuando se definió ese mismo componente como el mecanismo genérico para todos los clientes con necesidades similares — pasaron dos cosas al mismo tiempo: un downtime, porque el sistema no soportaba la carga real, y la confirmación de que la máquina virtual original nunca había tenido capacidad para sostener el volumen combinado de todos esos clientes.

La respuesta inmediata, como contención, fue crear un VM Scale Set en Windows para absorber la carga. Se necesitaron 5 instancias, con un costo de más de $1,500 dólares mensuales — para sostener, con más cómputo, un problema que en el fondo era de diseño, sin pruebas, y sin operación adecuada desde el origen.

El patrón que se repite: escalar en vez de preguntar por qué

Es exactamente el patrón que más me ha costado ver repetirse en 15 años de operación: cuando algo falla, la primera solución que se propone es agregar cómputo. El problema desaparece en el dashboard. El costo sube. Y la causa raíz —una instancia de Chrome que nunca se cierra— sigue ahí, esperando el siguiente pico de demanda para volver a manifestarse, ahora más cara de sostener.

La corrección real llegó después: se sugirió que ese componente podía vivir en Kubernetes, y se modernizó el consumo de la API específicamente para eliminar el desbordamiento de memoria en su origen — no para tolerarlo con más máquinas. El resultado fue doble: se ganó estabilidad, y se redujo el costo, resolviendo de fondo un problema de arquitectura que nunca tuvo supervisión técnica adecuada desde el diseño inicial.

El patrón tiene nombre y cifra en la industria

El reporte 2026 de Cast AI sobre optimización de Kubernetes, medido sobre decenas de miles de clústeres de producción, encuentra que los clústeres sin gestión desperdician entre 30% y 50% de su gasto total — y que programas estructurados de optimización (rightsizing, ajuste de autoscaler, limpieza de recursos no productivos) recuperan típicamente ese mismo rango, 30-50% del gasto del clúster. La migración de este caso específico — de un VM Scale Set reactivo a una arquitectura en Kubernetes con la causa raíz corregida — es prácticamente el caso de libro de por qué ese rango de ahorro existe.

La lección que me llevo

La misma que sostiene el primer artículo que escribí en este blog: el cómputo nunca es gratis, y escalarlo para tapar un diseño sin pruebas no es una solución — es posponer el costo real y hacerlo más grande mientras tanto.