Las preguntas sobre costos de nube suelen parecer simples.
- ¿Cuánto nos cuesta este cliente?
- ¿Qué tan cara es esta funcionalidad?
- ¿Qué equipos o productos están impulsando el gasto?
A pequeña escala, se responden fácilmente con estimaciones aproximadas. Pero a medida que los sistemas crecen, se vuelven, sin hacer ruido, algunas de las preguntas más difíciles de toda la organización.
No por falta de datos, sino porque la forma en que funciona la infraestructura moderna cambió.
El costo dejó de reflejar con claridad la propiedad
En entornos en etapa inicial, el costo suele alinearse con la propiedad. Un servicio pertenece a un equipo. Una base de datos sostiene a un producto. Un entorno corresponde a una función.
Cuando la infraestructura escala, ese modelo mental se rompe.
Los sistemas de hoy son:
- Altamente compartidos entre equipos y productos
- Están construidos sobre capas de plataforma que atienden a muchos consumidores
- Cada vez más multi-tenant por diseño
El costo ya no tiene un único dueño. Se distribuye entre distintos patrones de uso. En ese punto, preguntar "¿quién es dueño de esto?" deja de ser la pregunta correcta.
La infraestructura compartida oculta el consumo real
La mayoría de los costos de nube relevantes vive en capas compartidas:
- Pipelines de datos
- Plataformas de streaming
- Bases de datos
- Red y tráfico entre servicios
- Servicios de plataforma que sostienen múltiples workloads
Estos componentes rara vez se corresponden uno a uno con un equipo, una funcionalidad o un cliente.
En cambio, absorben el uso de toda la organización, muchas veces de forma desigual. Algunos equipos consumen mucho más que otros, pero ese desbalance es difícil de ver.
El resultado es opacidad en el costo, incluso cuando el gasto total sí se ve.
Por qué el unit economics se vuelve borroso a escala
Cuando el costo no se puede vincular directamente al uso, el unit economics se resiente.
A los equipos les cuesta:
- Explicar los márgenes por cliente o producto
- Entender qué funcionalidades son rentables
- Proyectar el gasto con precisión
- Tomar decisiones de arquitectura o de Precios con confianza
Finanzas ve números que no cuadran. Engineering ve una complejidad que los reportes no reflejan.
Todos sienten la brecha.
El verdadero problema es la atribución, no la visibilidad
El problema real no es la visibilidad. Es el modelo.
Cualquier organización puede ver su factura de nube.
Lo que se rompe es la correspondencia entre los recursos de nube y las preguntas de negocio que te hacen.
Los tags de nube sirven para representar propiedad simple. Pero las preguntas a nivel unitario rara vez son uno a uno:
- Un cliente usa muchos servicios.
- Un servicio atiende a muchos clientes.
- Un equipo de plataforma sostiene muchos productos.
- La infraestructura compartida y el tráfico de red no "pertenecen" a un único dueño.
Incluso con una disciplina de tagging impecable, los tags no alcanzan a expresar esa realidad de muchos a muchos ni la lógica de asignación que se necesita para responder preguntas como "costo por cliente", "costo por funcionalidad" o "qué equipo está subsidiando a cuál".
Por eso el unit economics se vuelve borroso a escala: los datos existen, pero el modelo de costos no refleja cómo se consume el sistema en la realidad. Es por eso que nuestro "FinOps sin tagging" es tan distinto.
Cómo lo abordan distinto los mejores equipos
Los equipos que operan a escala están empezando a replantearse cómo se modela el costo:
- Desde el uso, de abajo hacia arriba, en lugar de la propiedad, de arriba hacia abajo
- Desde los sistemas compartidos, en lugar de recursos aislados
- Desde el consumo real, en lugar de supuestos
Este cambio permite volver a explicar el costo a nivel unitario, incluso en entornos complejos.
Puedes ver cómo funciona esto en la práctica en este caso de estudio sobre cómo Akamai explica el costo a nivel unitario en infraestructura compartida sin depender del tagging:
O, si quieres ver cómo se aplica a tu entorno, puedes agendar una demo aquí