El requisito que aparece en la factura
Las revisiones de arquitectura suelen mirar si el diseño es seguro, si escala y si se puede operar. El costo aparece después, en la primera factura, cuando cambiar el diseño ya es caro. Entonces la conversación ya no es de arquitectura, sino de recortes.
Tratar el costo como requisito significa que una arquitectura no está terminada hasta que tiene una estimación de cuánto costará operarla, por componente y con sus supuestos escritos.
Estimar por componente
Una estimación útil no es una cifra total, sino una tabla:
- Cada componente con su costo mensual estimado.
- Los supuestos que lo determinan: tamaño, horas de uso, volumen de datos, región, tráfico de salida.
- Cómo crece con el uso: qué componentes escalan con los usuarios y cuáles son fijos.
- Qué se ahorraría con compromisos de uso, una vez estabilizado el consumo.
Los supuestos son tan importantes como los números: cuando la factura real se desvíe, mostrarán exactamente qué cambió.
Por qué corregir tarde sale caro
Cambiar una decisión de arquitectura cuesta poco en la pizarra y mucho en producción. Elegir mal el tipo de base de datos se corrige en minutos durante el diseño; en producción exige migración, ventana de corte y riesgo. Lo mismo con la región, el modelo de red o el reparto de servicios.
Por eso la estimación de costo va dentro del diseño, junto a cada registro de decisión, y no en un informe posterior.
Cómo encaja con FinOps
La estimación de diseño es el presupuesto inicial. Cuando el sistema entra en producción, el pipeline de costos mide el gasto real, lo asigna a cada componente y lo compara con la estimación. La diferencia entre lo estimado y lo real es la señal de que algo del diseño o del uso cambió, y su explicación se convierte en el siguiente registro de decisión.
Relacionado: Presupuesto y previsión (serie FinOps). Cómo lo aplicamos: Arquitectura Cloud.