El error no es elegir mal, es elegir sin preguntar
La mayoría de las startups no fracasan por elegir cloud o on-premise: fracasan por elegir sin haber hecho antes la pregunta correcta. La pregunta correcta nunca es "¿qué usa todo el mundo?" sino "¿qué necesita mi carga de trabajo, mi equipo y mi flujo de caja en los próximos 18 meses?".
Cloud se convirtió en el default por una razón lógica: baja la barrera de entrada, evita capex inicial y permite escalar rápido. Pero "default" no es sinónimo de "correcto". Y on-premise no es un dinosaurio: sigue siendo la opción más racional para ciertos perfiles de carga y compliance.
Los costos ocultos de la nube
El argumento de "pagás solo por lo que usás" es real, pero incompleto. Los costos que nadie pone en el pitch deck:
- Egress y transferencia de datos: mover información entre servicios o fuera del proveedor tiene un costo que crece con el volumen, y suele descubrirse recién en la primera factura grande.
- Sprawl de servicios: es fácil levantar instancias, buckets y funciones que nadie apaga. Sin gobernanza de recursos, el gasto se vuelve invisible hasta que aparece consolidado.
- Dependencia de arquitectura propietaria: cuanto más se usa el ecosistema nativo de un proveedor (funciones serverless, bases de datos gestionadas específicas), más caro y lento es migrar después.
Ninguno de estos puntos invalida la nube. La invalidan cuando se adopta sin control de gasto ni arquitectura pensada, solo porque "es lo que hace todo el mundo".
Los costos ocultos de on-premise
Del otro lado, el error simétrico es asumir que "tener el servidor propio" es más barato porque no hay factura mensual. La cuenta real incluye:
- Capex inicial (hardware, licencias, redundancia) que inmoviliza capital en una etapa donde el capital debería ir a producto.
- Personal especializado para mantenimiento, parches de seguridad y disponibilidad 24/7 — costo que muchas startups tempranas no pueden sostener con su equipo actual.
- Rigidez para escalar ante picos de demanda impredecibles, algo común en etapas de crecimiento temprano.
Cuándo tiene sentido cada opción
Algunos criterios prácticos, sin dogma:
- Carga predecible y estable (procesamiento batch constante, volumen conocido) → on-premise o cloud reservado suelen ser más eficientes en costo.
- Carga variable o en fase de validación de producto → cloud con auto-escalado tiene sentido, siempre con límites de gasto y alertas configuradas desde el día uno.
- Requisitos de compliance o soberanía de datos estrictos (sector salud, financiero, gobierno) → híbrido u on-premise pueden ser no negociables, independientemente del costo.
- Equipo técnico disponible → si no hay capacidad para operar infraestructura propia, cloud gestionado reduce riesgo operativo aunque cueste más por unidad.
Un ejemplo hipotético para ilustrar
Supongamos —como caso hipotético, no real— una startup que procesa imágenes de forma intensiva solo en picos estacionales de dos meses al año. Mantener servidores propios dimensionados para ese pico implica pagar capacidad ociosa el resto del año. En ese escenario hipotético, cloud con escalado automático sería la opción más racional. El caso inverso —procesamiento constante las 24 horas todo el año— invertiría la conclusión.
La conclusión que importa
La decisión de infraestructura no debería tomarse en una reunión de producto ni copiarse del stack de la startup que levantó la última ronda. Es una decisión de arquitectura que depende de datos concretos: patrones de carga, regulación aplicable, capacidad del equipo y horizonte de escalado real.
Antes de migrar, contratar o levantar un datacenter, el primer paso es auditar el proceso actual y proyectar la carga futura con datos, no con intuición ni tendencia. Esa auditoría —no la moda— es la que define si la nube da flexibilidad o solo da una factura sorpresa a fin de mes.