๐๐น ๐ฐ๐น๐ผ๐๐ฑ ๐ป๐ผ ๐ฒ๐ ๐ฐ๐ฎ๐ฟ๐ผ. ๐๐ ๐ฝ๐ฒ๐น๐ถ๐ด๐ฟ๐ผ๐๐ผ ๐๐ถ ๐ป๐ผ ๐๐ฎ๐ฏ๐ฒ๐ ๐บ๐ผ๐ฑ๐ฒ๐น๐ฎ๐ฟ๐น๐ผ.
๐๐น ๐ฐ๐น๐ผ๐๐ฑ ๐ป๐ผ ๐ฒ๐ ๐ฐ๐ฎ๐ฟ๐ผ. ๐๐ ๐ฝ๐ฒ๐น๐ถ๐ด๐ฟ๐ผ๐๐ผ ๐๐ถ ๐ป๐ผ ๐๐ฎ๐ฏ๐ฒ๐ ๐บ๐ผ๐ฑ๐ฒ๐น๐ฎ๐ฟ๐น๐ผ.
Se dice mucho que AWS, GCP o Azure son caros. Lo entiendo. Y casi siempre me parece intelectualmente perezoso.
El cloud rara vez es el problema. El problema es no saber quรฉ estรกs comprando. Cuando no puedes explicar cuรกnto te cuesta servir a un usuario activo o ejecutar una acciรณn concreta, no estรกs gestionando infraestructura. Estรกs operando a ciegas.
Lo delicado del cloud es su suavidad inicial. Te permite crecer sin CAPEX visible, todo parece variable y flexible. Esa ventaja es real. Pero esconde un riesgo: el coste marginal no se percibe en el momento en que decides una nueva feature.
Y es que cada funcionalidad que aรฑades suma llamadas, almacenamiento, procesos. A bajo volumen es irrelevante. El problema aparece cuando el uso escala. Necesitas redundancia, mรกs compute, mรกs observabilidad. Y el gasto deja de crecer de forma lineal.
A eso lo llamo coste marginal silencioso: recursos que consumes sin notarlo. Un Lambda que se ejecuta 1.000 veces al dรญa es inocente. 500.000 veces ya no. Dรฉjame ponerte un ejemplo numรฉrico sencillo, porque es donde se entiende todo.
๐ง๐ถ๐ฒ๐ป๐ฒ๐ ๐๐ป ๐ฆ๐ฎ๐ฎ๐ฆ ๐ฎ ๐ฎ๐ฌโฌ/๐บ๐ฒ๐.
Con 1.000 usuarios tienes 20.000โฌ de ingresos y 4.000โฌ de infraestructura. Margen sano.
Creces a 10.000 usuarios. 200.000โฌ de ingresos. Pero la infraestructura no pasa a 40.000โฌ, puede irse a 60.000 o 70.000โฌ porque necesitas bases de datos mรกs robustas, entornos segregados, mayor disponibilidad.
๐๐น ๐ฐ๐ผ๐๐๐ฒ ๐ฝ๐ผ๐ฟ ๐๐๐๐ฎ๐ฟ๐ถ๐ผ ๐๐ฎ ๐ป๐ผ ๐ฒ๐ ๐ฐโฌ, ๐๐ถ๐ป๐ผ ๐ณโฌ.
Nadie decidiรณ bajar el margen. Es complejidad acumulada. Crecimiento no lineal.
Esto se complica mรกs cuando el uso crece mรกs rรกpido que los ingresos. Pricing mal alineado, clientes intensivos, automatizaciones, integraciones con IA que multiplican llamadas a API. El volumen explota, la facturaciรณn no. Ahรญ el cloud deja de ser un problema tรฉcnico y se convierte en un problema de balance.
Antes de escalar, tres cosas:
-
๐๐ฎ๐น๐ฐ๐๐น๐ฎ ๐๐ ๐ฐ๐ผ๐๐๐ฒ ๐๐ป๐ถ๐๐ฎ๐ฟ๐ถ๐ผ ๐ฟ๐ฒ๐ฎ๐น. No el promedio mensual. Instrumenta cuรกnto consume cada acciรณn clave de tu producto.
-
๐ฆ๐ถ๐บ๐๐น๐ฎ ๐ฒ๐๐ฐ๐ฒ๐ป๐ฎ๐ฟ๐ถ๐ผ๐ ๐ฑ๐ฒ ๐ญ๐ฌ๐ . ยฟQuรฉ servicio rompe primero? ยฟDรณnde hay saltos de coste no lineales?
-
๐๐ป๐๐ถ๐ฒ๐ป๐ฑ๐ฒ ๐พ๐รฉ ๐ฎ๐๐๐ผ๐บ๐ฎ๐๐ถ๐๐ฎ๐ป ๐๐๐ ๐๐๐๐ฎ๐ฟ๐ถ๐ผ๐. Si tu pricing no captura intensidad de uso, estรกs regalando compute.
๐๐น ๐ฟ๐ถ๐ฒ๐๐ด๐ผ ๐ป๐ผ ๐ฒ๐ ๐น๐ฎ ๐ณ๐ฎ๐ฐ๐๐๐ฟ๐ฎ ๐ฎ๐น๐๐ฎ. ๐๐ ๐ป๐ผ ๐ฒ๐ป๐๐ฒ๐ป๐ฑ๐ฒ๐ฟ ๐ฐรณ๐บ๐ผ ๐ฒ๐๐ผ๐น๐๐ฐ๐ถ๐ผ๐ป๐ฎ ๐๐ ๐ฐ๐ผ๐๐๐ฒ ๐ฝ๐ผ๐ฟ ๐๐ป๐ถ๐ฑ๐ฎ๐ฑ ๐ฒ๐ฐ๐ผ๐ปรณ๐บ๐ถ๐ฐ๐ฎ ๐ฐ๐๐ฎ๐ป๐ฑ๐ผ ๐ฒ๐น ๐ป๐ฒ๐ด๐ผ๐ฐ๐ถ๐ผ ๐ฒ๐๐ฐ๐ฎ๐น๐ฎ. El cloud convierte coste fijo en variable. Pero la variabilidad exige disciplina analรญtica. Sin modelizaciรณn, la flexibilidad no es una ventaja. Es un riesgo que no ves venir.
