Jede Cloud-Plattform muss eine Art Kostenkennzahl für ihre Services haben. Bei den meisten Angeboten öffentlicher Clouds sind die Zielmetriken für Kosten üblicherweise die Anzahl der CPU-Kerne und die Menge des Speichers. Das wird mit der genutzten Zeit multipliziert und man erhält eine nutzungsbasierte Preisgestaltung.
Dieses Modell hat seine Vor- und Nachteile, schauen wir uns das daher etwas näher an.
Da alle Kosten an ein Nutzungsmuster gebunden sind, besteht das Ziel darin, Kosten durch reduzierte Nutzung zu senken.
Der Gesamtpreis kann einigermaßen abgeschätzt werden, indem man einfach die benötigte CPU-/Speichermenge über die Zeit aufsummiert. Das macht die Preisgestaltung einigermaßen planbar (mehr dazu bei den Nachteilen).
Unternehmen, die Wert auf Kostenplanbarkeit legen, wählen die Lösung, die diese gewährleistet. Wenn ich also sicher bezüglich der Kosten sein möchte, werde ich den am wenigsten flexiblen Weg wählen und auf Spitzenleistung skalieren. Das klingt zunächst kontraintuitiv (geldmäßig), aber das passiert häufig in großen Organisationen, da die meisten Planbarkeit der Kosten unvorhersehbaren Einsparungen vorziehen.
Jeder hat eine ungefähre Vorstellung davon, was eine CPU/vCPU ist, aber tatsächlich ist das kein guter Maßstab für den Vergleich zwischen Anbietern. Ich muss immer meine eigenen Benchmarks durchführen, um zu sehen, wie Instanztypen, CPU-Architektur und vertikale Skalierung meine Leistung beeinflussen.
Die variable Rechenleistung der CPU macht es auch sehr schwierig, den tatsächlichen Einfluss, z. B. auf die Umwelt, für mein Projekt zu vergleichen. Einige Anbieter sind bereits vorangegangen und stellen CO2- (oder CO2-Äquivalent-)Metriken zur Verfügung, aber auch diese werden sehr komplex, da es schwer wird zu verstehen, was enthalten ist und was nicht.
Nutzungbasierte Preisgestaltung ist also ein großer Fortschritt im Vergleich dazu, einfach einen monatlichen Betrag zu zahlen, ohne dass sich jemand Gedanken darüber macht, was das eigentlich bedeutet. Es versucht auch, einen Anreiz zur Reduktion des Gesamtabdrucks zu geben, bietet aber nur begrenzte Möglichkeiten, Services Anbieter-übergreifend zu vergleichen.
Vielleicht ist es daher Zeit, nutzungsbasierte Preisgestaltung einen Schritt weiter zu denken und die zugrundeliegende Metrik zu ändern.
Wenn wir also mit CPU- und Speichernutzung über Zeit starten, können wir die Menge der auf Anbieterebene genutzten Ressourcen erfassen. Eine Metrik, die hier fehlt, oder die wir einfach in die Kosten einbeziehen, ist die Leistung (im Sinne von verbrauchten Watt).
Statt also Kosten durch Verarbeitung und einen Umwelt-Fußabdruck durch eine CO2-Metrik getrennt zu berechnen, wie wäre es, wenn wir beides zusammenführen und die Rechenleistung in Watt berechnen? So könnten wir eine Metrik für Kosten und Impact liefern.
Damit würde ein Unternehmen, das seinen ökologischen Fußabdruck verbessern möchte, automatisch auch seine Kosten senken – und umgekehrt. Beide Ziele wären sichtbar und handhabbar.
Das führt zur Frage, wie das funktionieren soll, denn theoretisch klingt das alles einfach. Tatsächlich gibt es jedoch ein großes Problem: Unsere aktuelle Hardware liefert nicht die benötigte Auflösung für solche Metriken.
Für den Moment müssen wir daher schätzen und mit den derzeitigen Hardware-Limitationen arbeiten.
Was wir bisher implementiert haben, ist ein Stromzähler an jeder Maschine; so kennen wir den Gesamtenergieverbrauch (mit Minutengenauigkeit). Diese Metrik wird mit der nutzerbasierten Arbeitslast auf diesen Maschinen verknüpft. Das gibt uns eine Schätzung, wie viel Energie von welchem Nutzer verbraucht wurde. Wir möchten diese Metrik auch so bald wie möglich in der UI anzeigen.
Das ist also unser erster Versuch zu diesem Thema. Wir werden ein weiteres Update geben, falls wir Fortschritte in diese Richtung sehen oder auf Probleme stoßen, die diese Idee schlecht machen.
Für den Moment sieht das nach dem richtigen Weg aus.