Chaque plateforme cloud doit avoir une métrique de coût associée à ses services. Pour la plupart des offres de cloud public, les métriques cibles pour le coût sont généralement le nombre de cœurs CPU et la quantité de mémoire. Cela est multiplié par la durée d’utilisation et nous obtenons un tarif basé sur l’utilisation.
Ce modèle a ses avantages et ses inconvénients, alors explorons un peu cela.
Puisque tout coût est lié à un modèle d’utilisation, l’objectif est de réduire le coût en réduisant l’utilisation.
Le prix global peut être en quelque sorte estimé en additionnant simplement la quantité requise de CPU/Mémoire sur le temps. Cela rend les tarifs assez prévisibles (plus à ce sujet dans les inconvénients).
Les entreprises qui visent la prévisibilité des coûts choisiront la solution qui la garantit. Donc si je veux être sûr du coût, je choisirai la voie la moins flexible et dimensionnerai pour la performance maximale. Cela semble contre-intuitif au départ (financièrement), mais c’est souvent ce qui arrive dans les grandes organisations car la plupart préfèrent la prévisibilité à des économies de coût imprévisibles.
Tout le monde a une idée de ce qu’est un CPU/vCPU, mais ce n’est en réalité pas une bonne métrique pour comparer entre fournisseurs. Je dois toujours faire mes propres benchmarks pour voir comment les types d’instances, l’architecture CPU, et le scaling vertical affectent mes performances.
La puissance de traitement CPU variable rend aussi très difficile la comparaison de l’impact réel, comme l’impact environnemental, pour mon projet. Certains fournisseurs ont déjà pris l’initiative et rendent disponibles des métriques CO2 (ou équivalent CO2), mais même celles-ci deviennent très complexes car il devient plus difficile de comprendre ce qui est inclus et ce qui est exclu.
Ainsi, avoir un tarif basé sur l’utilisation est une grande avancée comparé au simple paiement d’un montant mensuel sans que personne ne s’en soucie. Cela tente aussi de donner un incitatif à réduire l’empreinte globale, mais offre aussi des capacités limitées pour comparer les services entre fournisseurs.
Peut-être est-il temps donc d’aller un pas plus loin avec la tarification basée sur l’usage et de changer la métrique ici.
Donc si nous partons de la consommation CPU et mémoire dans le temps, nous pouvons saisir la quantité de ressources utilisées au niveau du fournisseur. Une métrique qui nous manque ici, ou que nous incluons simplement dans le prix, est la puissance (en watts consommés).
Donc au lieu d’avoir un coût calculé par traitement, et une empreinte environnementale calculée via une métrique CO2, que diriez-vous de fusionner les deux et de calculer la puissance de traitement en watts. De cette façon, nous pouvons fournir une métrique unique pour le coût et l’impact.
Ainsi, une entreprise qui voudrait améliorer son empreinte environnementale améliorerait automatiquement son coût et vice versa. Les deux objectifs seraient visibles et exploitables.
Cela mène à la question de comment cela devrait fonctionner, car en théorie tout cela semble simple. En réalité, il y a un gros problème, notre matériel actuel ne fournit pas ce type de métriques avec la résolution dont nous avons besoin.
Donc pour le moment nous devons estimer et contourner les limitations de notre matériel actuel.
Ce que nous avons implémenté pour l’instant est un compteur de puissance sur chaque machine, ainsi nous connaissons la quantité totale d’énergie consommée (avec une résolution à la minute). Cette métrique est superposée à la charge de travail utilisateur sur ces machines. Ce que cela nous donne est une estimation de la quantité d’énergie consommée par quel utilisateur. Nous voulons aussi intégrer cette métrique dans l’interface utilisateur dès que possible.
Ainsi c’est notre première tentative sur ce sujet. Nous fournirons une autre mise à jour si nous voyons des avancées dans cette direction ou si nous rencontrons des problèmes qui en font une mauvaise idée.
Pour l’instant, cela semble être la voie à suivre.