Toda plataforma en la nube debe tener alguna métrica de costo asociada a sus servicios. Para la mayoría de las ofertas públicas en la nube, las métricas objetivo para el costo suelen ser el conteo de núcleos de CPU y la cantidad de memoria. Eso se multiplica por el tiempo usado y llegamos a un precio basado en el uso.
Este modelo tiene sus pros y sus contras, así que vamos a iterar 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 total puede estimarse en cierta medida sumando solo la cantidad requerida de CPU/Memoria a lo largo del tiempo. Esto hace que el precio sea algo predecible (más sobre eso en la sección de Contras).
Las empresas que buscan previsibilidad en el costo elegirán la solución que se lo dé. Así que si quiero estar seguro sobre el costo, elegiré el camino menos flexible y escalaré al rendimiento máximo. Esto suena contraproducente al principio (en términos de dinero), pero sucede a menudo en organizaciones grandes, ya que la mayoría prefiere la previsibilidad frente a algunos ahorros impredecibles.
Todos tienen alguna idea de qué es una CPU/vCPU, pero en realidad no es una buena métrica para comparar entre proveedores. Siempre tengo que hacer mi propio benchmarking para ver cómo los tipos de instancia, la arquitectura de CPU y el escalado vertical afectan mi rendimiento.
La potencia variable de procesamiento de la CPU también dificulta mucho comparar el impacto real, como el impacto ambiental, para mi proyecto. Algunos proveedores ya han dado un paso adelante y ponen métricas de CO2 (o equivalente de CO2) disponibles, pero incluso estas se vuelven muy complejas cuando es difícil entender qué está incluido y qué está excluido.
Así que tener un precio basado en el uso es un gran avance en comparación con simplemente pagar una cantidad mensual sin que nadie se preocupara por lo que eso implica. También intenta dar un incentivo para reducir la huella total, pero ofrece solo capacidades limitadas para comparar servicios entre proveedores.
Tal vez sea hora de llevar el precio basado en el 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 simplemente incluir en el precio, es la energía (como en vatios consumidos).
Así que 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 la potencia de procesamiento en vatios? De esta forma podemos proporcionar una métrica para costo e impacto.
De esta forma, una empresa que quisiera mejorar su huella ambiental automáticamente mejoraría 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 realidad, hay un gran problema: nuestro hardware actual no provee este tipo de métricas con la resolución que necesitamos.
Así que por ahora debemos estimar y trabajar alrededor de las limitaciones de nuestro hardware actual.
Lo que hemos implementado por ahora es un medidor de energía en cada máquina, de esta forma sabemos la cantidad total de energía consumida (con resolución de minutos). Esta métrica se superpone a la carga de trabajo basada en usuario en esas máquinas. Lo que esto nos da es una estimación de cuánta energía fue consumida por qué usuario. También queremos incorporar esta métrica en la interfaz de usuario lo antes posible.
Este es nuestro primer intento en este tema. Proporcionaremos otra actualización si vemos avances en esta dirección o si nos topamos con problemas que hagan que esta sea una mala idea.
Por ahora, esto parece ser el camino a seguir.