El mito de la escalabilidad infinita
La promesa de la nube es simple: escalá cuando lo necesites, pagá solo por lo que usás. En la práctica, muchas empresas terminan haciendo lo contrario: aprovisionan de más "por las dudas", dejan autoscaling mal configurado, o replican arquitecturas de otros que no tienen nada que ver con su tráfico real. El resultado es capacidad fantasma: recursos que están ahí, facturando, sin que nadie los use.
Esto no es un problema de la nube. Es un problema de diseño y de gobernanza.
Por qué se llega a este punto
Hay tres causas recurrentes:
- Miedo al downtime. Ante la duda, se sobredimensiona. Es más fácil justificar un servidor de más que explicar una caída en producción.
- Autoscaling configurado con valores por defecto. Umbrales genéricos (CPU al 70%, por ejemplo) que no reflejan el comportamiento real de la aplicación, generan instancias que se levantan y no bajan cuando deberían, o que escalan de forma lenta ante picos reales.
- Falta de visibilidad de costos por servicio. Si nadie mide cuánto cuesta cada componente en relación a su uso, no hay forma de detectar el desperdicio hasta que llega la factura.
El costo real de escalar sin criterio
Cada instancia, contenedor o función que corre sin carga asociada es dinero quemado. No es solo el costo directo del recurso: es el tiempo de ingeniería que se va en mantener una arquitectura sobredimensionada, la complejidad operativa innecesaria, y la falsa sensación de seguridad que impide optimizar.
Un ejemplo hipotético para ilustrar el patrón: una empresa que recibe picos de tráfico solo dos horas al día (por ejemplo, en un proceso de facturación nocturno) pero mantiene la capacidad máxima activa las 24 horas. Ese desperdicio, multiplicado por 22 horas diarias de sobreaprovisionamiento, es exactamente el tipo de gasto que una auditoría de arquitectura debería detectar y corregir.
Cómo dimensionar correctamente
1. Medí antes de escalar. Establecé métricas de utilización real (CPU, memoria, requests por segundo, latencia) y compará contra la capacidad asignada. Si el ratio de uso promedio está muy por debajo del aprovisionado, hay margen de ajuste.
2. Diseñá para el patrón de demanda, no para el pico teórico. Si tus picos son predecibles (fin de mes, campañas, horarios específicos), usá scheduled scaling en vez de depender solo de autoscaling reactivo. Si son impredecibles pero cortos, evaluá arquitecturas serverless o basadas en eventos, donde el costo está directamente atado a la ejecución.
3. Combiná modelos de pricing. Instancias reservadas o de ahorro para la carga base y predecible, spot o on-demand para los picos. Mezclar modelos de compra según el tipo de carga reduce el costo sin sacrificar capacidad de respuesta.
4. Hacé load testing con datos reales. Simular tráfico real antes de definir umbrales de autoscaling evita configurar por intuición.
5. Establecé revisiones periódicas. El dimensionamiento no es una decisión de una sola vez. La demanda cambia, el código cambia, y la arquitectura debería revisarse con la misma frecuencia con la que cambia el negocio.
Gobernanza, no heroísmo
Escalar bien no depende de un ingeniero que "tiene el ojo entrenado". Depende de procesos: tagging consistente de recursos, dashboards de costo por servicio, políticas de autoscaling documentadas y revisadas, y una cultura donde el costo de infraestructura se discute con la misma seriedad que la performance.
En Tinto & Bots trabajamos justamente ese cruce: auditamos la arquitectura actual para identificar dónde está la capacidad fantasma, y diseñamos el despliegue cloud para que escale según el comportamiento real del negocio, no según el miedo o la plantilla por defecto. Pagar por lo que se usa no es una frase de marketing de proveedor cloud: es un resultado de diseño.