Cada plataforma en la nube debe tener alguna métrica de costo asociada a sus servicios. Para la mayoría de las ofertas de nube pública, las métricas objetivo para el costo suelen ser el número de núcleos de CPU y la cantidad de memoria. Eso se multiplica por el tiempo usado y se llega a un precio basado en el uso.
Este modelo tiene sus pros y sus contras, así que iteremos un poco sobre esto.
Dado que todo el costo está ligado a un patrón de uso, el objetivo es reducir el costo reduciendo el uso.
El precio general puede estimarse sumando la cantidad requerida de CPU/Memoria a lo largo del tiempo. Esto hace que el precio sea algo predecible (más sobre esto en los Contras).
Las empresas que buscan predictibilidad en el costo elegirán la solución que la brinde. Así que si quiero estar seguro sobre el costo, elegiré la ruta menos flexible y escalaré al rendimiento máximo. Esto suena contraproducente al principio (en términos económicos), pero sucede a menudo en grandes organizaciones porque la mayoría prefiere la predictibilidad sobre algunos ahorros impredecibles.
Todos tienen una idea de lo que es una CPU/vCPU, pero en realidad no es una buena métrica para comparar entre proveedores. Siempre tengo que hacer mis propios benchmarks para ver cómo los tipos de instancia, la arquitectura de CPU y el escalado vertical afectan mi rendimiento.
El poder variable de procesamiento de la CPU también hace muy difícil comparar el impacto real, como por ejemplo el impacto ambiental, para mi proyecto. Algunos proveedores ya han dado un paso adelante y hacen métricas de CO2 (o equivalente en CO2) disponibles, pero incluso estas se vuelven muy complejas ya que es difícil entender qué está incluido y qué está excluido.
Tener un precio basado en uso es un gran avance comparado con solo pagar una cantidad mensual sin que nadie importara lo que eso implicaba. También intenta dar un incentivo para reducir la huella overall, pero da capacidades limitadas para comparar servicios entre proveedores.
Así que tal vez sea hora de llevar el precio basado en uso un paso más allá y cambiar la métrica aquí.
Si empezamos con el consumo de CPU y memoria a lo largo del tiempo, podemos capturar la cantidad de recursos utilizados a nivel del proveedor. Una métrica que nos falta aquí, o que solo se incluye en el precio, es la energía (como los vatios consumidos).
Entonces, en lugar de tener un costo calculado por procesamiento y una huella ambiental calculada a través de alguna métrica de CO2, ¿qué tal si unimos esos dos y calculamos el poder de procesamiento en vatios? De este modo, podemos proporcionar una métrica para costo e impacto.
Así, una empresa que quisiera mejorar su huella ambiental mejoraría automáticamente su costo y viceversa. Ambos objetivos serían visibles y accionables.
Esto lleva a la pregunta de cómo debería funcionar, porque en teoría todo suena simple. En la práctica, hay un gran problema: nuestro hardware actual no proporciona este tipo de métricas con la resolución que necesitamos.
Así que por ahora tenemos que estimar y trabajar alrededor de nuestras limitaciones de hardware actuales.
Lo que hemos implementado por ahora es un medidor de energía en cada máquina, de este modo sabemos la cantidad total de energía consumida (con resolución de un minuto). Esta métrica se sobrepone a la carga de trabajo por usuario en esas máquinas. Lo que esto nos da es una estimación de cuánta energía fue consumida por cada usuario. También queremos llevar esta métrica a la interfaz de usuario lo antes posible.
Así que este es nuestro primer intento en este tema. Proporcionaremos otra actualización si vemos movimientos en esta dirección o si encontramos problemas que hagan que esta sea una mala idea.
Por ahora, esto parece ser el camino a seguir.