De licencias caras a OSS: recorte de costes en Kubernetes
Algunos de los mayores ahorros en tecnología nunca llegan a una presentación inaugural ni a una página de marketing reluciente. Se consiguen en lo más profundo de las arquitecturas de infraestructura, en rincones que la mayoría de los equipos ni se plantea cuestionar. Todo empieza con una auditoría de DevOps y termina con un ahorro económico contundente.
Esta es una de esas historias: un equipo ahorró $100,000 haciendo algo que más organizaciones deberían hacer, que es preguntarse: un momento, ¿por qué estamos usando esto?
El escenario: Kubernetes estándar y sobrecostes habituales
Este proyecto en particular arrancó con una tarea bastante rutinaria: configurar Prometheus para el monitoreo de Kubernetes. Algo sencillo en apariencia. La infraestructura era madura, estable y extrañamente cara.
En cuanto el equipo empezó a inspeccionar los componentes, algo llamó la atención. En mitad del stack se encontraba un API gateway de nivel empresarial sin apenas tráfico ni reglas complejas de enrutamiento; una pieza de middleware sobredimensionada que parecía más una reliquia corporativa que un servicio indispensable.
Y la empresa estaba a punto de renovar esa licencia por otros $100K. Cien mil dólares a tres años vista para gestionar un volumen de peticiones que probablemente cabría en una Raspberry Pi.
El cambio: Kong OSS al rescate
El equipo hizo lo que cualquier buen detective de infraestructura debería hacer: sustituirlo.
Implementaron Kong OSS, un API gateway de código abierto, en su lugar. Además de replicar la funcionalidad original, simplificó la arquitectura, reemplazando un diseño innecesariamente complejo por un enrutamiento limpio y con un propósito claro. El rendimiento no varió, el consumo de recursos se redujo y el conjunto pasó a ser mucho más mantenible. Y, de paso, desapareció una partida de gasto de $100,000.
Ese momento de lucidez se convirtió en costumbre. Ahora, cada vez que colaboran en labores de DevOps o monitoreo, revisan a fondo el resto del stack. Y el patrón se repite constantemente: herramientas heredadas que nadie pone en duda, restos dejados por consultores del pasado, soluciones sobredimensionadas, infrautilizadas y a precios desorbitados.
Sobredimensionar por defecto
Lo llamativo es lo habitual que resulta este escenario. Un ingeniero contaba que su empresa pagaba $50K al año por una herramienta que en la práctica ejecutaba sentencias condicionales if decoradas. Otro explicaba que redujo los costes de la nube desde más de $100K+ hasta menos de $20K simplemente migrando a EKS y optimizando el tipo de instancias.
Hablamos de mallas de servicios obsoletas que ya no enrutan nada, plataformas de monitoreo empresarial donde el 80% de las funciones se solapa con utilidades de código abierto ya instaladas, y sistemas de CI/CD con licencias corporativas carísimas utilizadas solo por dos personas en toda la compañía.
Un comentario en foros lo resumía con precisión: los equipos heredan tecnología elegida por arquitectos de hace tres generaciones y nunca la cuestionan.
Un problema tanto cultural como de costes
El factor financiero pesa, sin duda. Pero este caso también refleja cómo la inercia termina convirtiéndose en norma.
En el software corporativo, las herramientas suelen sobrevivir a las razones que motivaron su compra. Eso no parece importar hasta que llega la notificación de renovación y te encuentras frente a un error de seis cifras.
A veces el producto se mantiene porque un directivo firmó el contrato inicial. En otras ocasiones, el gasto se camufla bajo un concepto difuso de soporte. Y en muchos casos nadie contempla alternativas sencillamente porque la herramienta siempre ha estado ahí.
Así surge el exceso de gasto en la empresa: la mayoría de las veces por falta de atención, no por mala intención.
El argumento del código abierto (con matices)
Esto no significa que debas desmantelar cada software de pago para sustituirlo por código abierto. Las soluciones empresariales existen por buenos motivos, especialmente cuando necesitas acuerdos de nivel de servicio (SLA), soporte preferente y la tranquilidad de que alguien responderá al teléfono a las 3 a.m. Con demasiada frecuencia, sin embargo, las empresas pagan por herramientas que no guardan relación con sus necesidades reales.
Varios ingenieros señalaban que al migrar a herramientas de código abierto, sobre todo en métricas, ahorraron dinero y ganaron visibilidad, olvidándose de las tarifas por métrica individual. Una compañía sustituyó su plataforma SaaS de métricas por Prometheus + Thanos y redujo su coste por serie en un 95%. Como era de esperar, pasaron a monitorizar 50x más volumen de datos.
Un usuario lo sintetizaba así: a veces el único motivo por el que se mantienen arquitecturas austeras es por el precio. Eso actúa más como una traba que como una estrategia.
Qué puedes hacer en la práctica
La mayor parte de estos ahorros partió de preguntas básicas: ¿de verdad necesitamos esto?, ¿qué función cumple exactamente?, ¿podría resolverlo algo más simple?
No hace falta ser un especialista avanzado en Kubernetes para plantearse estas cuestiones. Solo se requiere curiosidad y cierta determinación.
Cada vez más equipos incorporan revisiones de racionalización del stack en cada auditoría, forme o no parte del encargo inicial. El objetivo es ajustar las herramientas al problema real, y a menudo la dificultad principal radica en gestionar las susceptibilidades internas sobre quién eligió esa herramienta en su momento.
Busca las trampas ocultas
Aquí hay una valiosa lección para cualquier desarrollador, operador o responsable con capacidad de decisión sobre la infraestructura: trata tu stack como un organismo vivo que conviene revisar, refactorizar y poner a prueba con regularidad.
Es muy probable que descubras que ese gateway de precio desorbitado puede sustituirse por algo que cabe en un Dockerfile, que la suite de monitoreo con cinco paneles que nadie consulta puede cambiarse por una instalación de Grafana bajo tu control, y que ese clúster sobrecargado de máquinas virtuales puede migrar a contenedores que escalan gracias a su simplicidad.
No necesitas ser una startup para operar con mentalidad ágil. Incluso las grandes corporaciones se benefician de una limpieza a fondo apoyada en software de código abierto.
Reflexión final: la simplicidad gana
Kubernetes y los API gateways son solo los ejemplos visibles. El hábito decisivo que hay que desterrar es el conformismo de asumir que debe quedarse porque ya estaba ahí.
Bajo el capó de muchos sistemas modernos hay bombas de relojería de $100K esperando el momento de renovarse. Para desactivarlas solo hace falta que alguien se atreva a preguntar: ¿de verdad seguimos necesitando esto? A menudo, el movimiento más inteligente consiste en retirar lo que ya no aporta valor en lugar de construir otra capa encima.