Commitment-Rabatte sind komplex und kosten viel Zeit und Geld.
Commitment-Rabatte sind komplex und kosten viel Zeit und Geld. Mit Automatisierung holen Sie diese Einsparungen mit minimalem Aufwand und Risiko heraus.
Solange es die Public Cloud gibt, suchen Anwender nach neuen Wegen, ihre Ausgaben zu optimieren und zu verhindern, dass die Cloud-Kosten aus dem Ruder laufen. Storage- oder Datenbanknutzung zu optimieren, hilft durchaus – das größte Potenzial zur Senkung Ihrer Public-Cloud-Kosten liegt aber bei den Compute-Ausgaben. Compute-Kosten machen typischerweise 50 bis 80 % der gesamten Cloud-Rechnung aus. Es liegt also auf der Hand, dass hier der größte Hebel sitzt, wenn Sie Ihre Public-Cloud-Kosten insgesamt drücken wollen.
Die gute Nachricht: Public-Cloud-Anbieter wie Amazon Web Services (AWS) und Google Cloud Platform (GCP) gewähren erhebliche Compute-Rabatte für alle, die sich für 1 oder 3 Jahre auf eine bestimmte Nutzungsmenge festlegen können (je länger das Commitment, desto höher der Rabatt – logisch).
Die schlechte Nachricht: Wer diese Commitment-Rabatte nutzen will, steht vor zwei zentralen Herausforderungen:
- den Compute-Bedarf für die nächsten ein oder drei Jahre präzise zu prognostizieren
- die Nutzung über die gesamte Laufzeit so zu steuern, dass die Ziele auch tatsächlich erreicht werden
Gerade für junge, digitalgetriebene Unternehmen, die ihre cloudbasierten Systeme und Anwendungen noch hochskalieren, sind diese Hürden hoch. Es fehlt häufig an Ressourcen oder finanziellem Spielraum, um Risiko und Verwaltungsaufwand eines Commitment-Portfolios zu schultern – und gleichzeitig lässt sich kaum abschätzen, wie der Bedarf in drei Monaten aussieht, geschweige denn in drei Jahren. Auch größere Unternehmen geraten ins Straucheln, wenn Infrastruktur- und Commitment-Bedarf über mehrere Teams verteilt sind und die Kostenkontrolle entsprechend komplex wird.
Compute-Bedarf prognostizieren
Je nach Aufstellung Ihres Unternehmens kann ein einzelnes Team für die Prognose der Public-Cloud-Infrastruktur zuständig sein, oder die Aufgabe verteilt sich auf mehrere Teams mit jeweils eigenen Projekten und Anforderungen.
Wie auch immer Sie das organisieren – sich über einen langen Zeitraum auf ein bestimmtes Compute-Niveau festzulegen, ist riskant: Wer zu viel reserviert, verbrennt Geld für ungenutzte Compute-Instanzen; wer zu wenig reserviert, zahlt am Ende Premium-Preise für On-Demand-Instanzen.
Höhere Rabatte bekommen Sie von den Cloud-Anbietern, wenn Sie Ihre Compute-Commitments präziser fassen – etwa indem Sie sich auf bestimmte Maschinentypen oder Regionen festlegen. Genauso wichtig ist es jedoch, beim Kauf von Commitments Flexibilität mitzudenken. Public-Cloud-Umgebungen entwickeln sich rasant; ändert sich Ihre Software oder Ihr Geschäftsmodell, müssen Sie Ihre Umgebung womöglich umkonfigurieren. Wenn Sie dann ein Commitment ohne entsprechende Flexibilität gekauft haben, bleiben Sie auf den Kosten sitzen.
Bevor wir uns die verschiedenen Commitment-Typen und ihre jeweilige Flexibilität ansehen, sollten Sie bei der Prognose Ihres Compute-Bedarfs vor allem an Folgendes denken:
- Interner Geltungsbereich
Wer wird das Commitment nutzen? Teilen sich mehrere Teams in Ihrer DevOps-Organisation ein gemeinsames Commitment, oder ist es sinnvoller, für jedes Team eigene Commitments zu kaufen?
- Laufzeit des Commitments
Wie weit in die Zukunft wollen Sie sich festlegen? Wenn Sie Ihren Bedarf gut kennen und konsistente Spezifikationen haben, lohnt sich für eine Grundlast (z. B. 50 % der Prognose) ein 3-Jahres-Commitment, um die Einsparungen zu maximieren. Den Rest decken Sie über eine Mischung aus 1-Jahres-Commitments und/oder On-Demand-Instanzen ab.
- Services
Brauchen Sie nur klassisches Infrastructure-as-a-Service-Compute (also EC2 oder GCE)? Setzen Sie Container ein? Serverless? Kubernetes? Falls ja: Lässt sich all das über dasselbe Commitment abdecken, oder verteilen Sie es besser auf mehrere? Bedenken Sie: Mehr Commitments bringen mehr Flexibilität, aber auch mehr Verwaltungsaufwand.
- Maschinentypen
Welche Maschinentypen und -größen brauchen Ihre Teams für Ihr digitales Angebot? Und ist denkbar, dass sich dieser Bedarf in den nächsten ein bis drei Jahren ändert?
- Regionen
Kurzfristig ist meist klar, in welchen Regionen Sie Maschinen hochfahren müssen. Sobald Ihr Geschäft oder Ihre Nutzerbasis aber in neue Märkte expandiert, wird das schnell aufwendig. Sie müssen einschätzen, ob sich Ihre Regionen ändern könnten – und falls ja, ob Ihr Commitment diese Flexibilität bietet oder ob Sie für das Wachstum zusätzliche Commitments brauchen.
Wenn Sie diese Fragen beantwortet haben, geht es an die Auswahl des passenden Commitment-Typs. Sowohl AWS als auch GCP bieten mehrere Compute-Commitment-Pläne mit unterschiedlich viel Flexibilität. Grob lassen sie sich in zwei Gruppen einteilen:
- Ressourcenbasierte Commitments setzen eine bestimmte Nutzungsmenge auf Basis vorab festgelegter Spezifikationen voraus. Bei AWS sind das Reserved Instances (RIs) bzw. Convertible RIs. Bei GCP heißen sie Committed Use Discounts (CUDs).
- Ausgabenbasierte Commitments erlauben es, sich auf ein bestimmtes Ausgabenniveau festzulegen – unabhängig von Ressourcenspezifikationen. Diese zusätzliche Flexibilität geht mit geringeren Rabatten einher. Bei AWS firmieren sie als Savings Plans (SPs), bei GCP als FlexCUDs.
Zum Vergrößern anklicken
Wie die Grafik oben zeigt, ergeben die Public Cloud(s), auf denen Sie aufbauen, und die jeweiligen Flexibilitätsstufen eine Vielzahl an Optionen – aus denen Sie die für Ihre Anforderungen passendste auswählen müssen.
Für AWS-Anwender kommt erschwerend hinzu, dass sich Standard-RIs auf dem AWS Marketplace weiterverkaufen lassen, um die Kosten ungenutzter Instanzen aus überdimensionierten Käufen zumindest teilweise zurückzuholen. Eine Garantie, einen Käufer für genau diese workloads zu finden, gibt es jedoch nicht – und selbst wenn: Der Verkaufsprozess bedeutet zusätzliche Komplexität und Zeitaufwand für die Person im Team, die diese Aufgabe übernimmt.
Commitments verwalten und nachhalten
Sie haben Ihren Compute-Bedarf prognostiziert und auf dieser Basis Commitments gekauft – damit ist die Arbeit aber noch lange nicht erledigt. Das Management des Commitment-Portfolios ist mindestens so wichtig wie die Prognose vor dem Kauf, wenn nicht wichtiger. Denn egal, wie gut Sie planen: Ihre Umgebung wird sich nahezu immer verändern, oder es entstehen neue Anforderungen, für die zusätzliche Commitments im Portfolio nötig werden.
Vor diesem Hintergrund lohnt ein Blick auf die Punkte, die Sie über den gesamten Lebenszyklus Ihrer Commitments im Auge behalten sollten:
- Balance zwischen Commitments und On-Demand-workloads
Im Abschnitt zur Prognose haben wir es schon angerissen: Wenn Ihr Compute-Bedarf wächst, müssen Sie entscheiden, wie viel davon über 1- oder 3-Jahres-Commitments abgedeckt wird – und wie viel On-Demand bleibt.
- Regionale Expansion
Wächst Ihr Geschäft oder Ihr Service-Angebot? Wollen Sie Nutzer in neuen Märkten erreichen? Wenn Sie nicht ohnehin durch ein ausgabenbasiertes Commitment abgedeckt sind (also einen Compute SP bei AWS oder FlexCUD bei GCP), werden Sie für die neuen Regionen aller Voraussicht nach zusätzliche Commitments brauchen.
- Laufendes Tracking und Monitoring der Nutzung
Es ist entscheidend zu wissen, ob Sie über die gesamte Laufzeit eines Commitments auf Kurs sind, Ihre Nutzungsziele zu erreichen. Schwierig wird das, wenn Ihre Nutzung über die Laufzeit hinweg schwankt – etwa durch Veränderungen in Ihrer Nutzerbasis oder saisonale Effekte in Ihrem Geschäftsmodell. So oder so wollen Sie wissen, ob Sie Ihre Reservierungen überschreiten und Mehrkosten zahlen werden (oder neue Commitments für die Differenz brauchen) – oder ob am Ende der Laufzeit ungenutzte workloads übrig bleiben.
- Verlängerungen
Im Rahmen des Trackings müssen Sie auch entscheiden, was beim Auslaufen eines Commitments passieren soll: ein neues kaufen, neu konfigurieren oder einfach auslaufen lassen? Diese Aufgabe wird umso komplexer, je größer Ihr Commitment-Portfolio wird und je mehr unterschiedliche Verlängerungs- und Ablaufdaten sich übers Jahr verteilen.
Wo ist der Easy-Button? 
Wenn Ihnen bei all diesen Faktoren der Kopf schwirrt, sind Sie damit ganz sicher nicht allein. Das Management eines Commitment-Portfolios ist so aufwendig und mit so spürbaren Risiken verbunden, dass viele Unternehmen ganz darauf verzichten und sich – trotz höherer Kosten – ausschließlich auf On-Demand-workloads stützen.
Es geht aber auch anders: Sie können Ihre Compute-Commitments automatisieren und damit Risiko und Verwaltungsaufwand auf einen Schlag aus dem Weg räumen. Genau dafür wurde DoiT Flexsave™ entwickelt. Per Machine Learning analysiert Flexsave Ihre laufenden Compute-Ausgaben, identifiziert AWS-workloads, die nicht bereits durch bestehende Rabatte (also SPs, RIs, Spot oder Enterprise Discount Programs) abgedeckt sind, und wendet auf diese On-Demand-workloads automatisch das Äquivalent eines 1-Jahres-Savings-Plans an.
"Ohne Flexsave könnten wir Commitment-basierte Rabatte vermutlich gar nicht nutzen; jetzt erzielen wir die Einsparungen mit praktisch null Aufwand." – Kyâne Pichou
Mit dieser Methode haben Hunderte Flexsave-Kunden in den letzten Jahren Einsparungen in Millionenhöhe erzielt – darunter auch die E-Commerce-Plattform Phenix, die seit der Aktivierung von Flexsave über 25 % bei ihren On-Demand-Compute-workloads spart. "Ohne Flexsave könnten wir Commitment-basierte Rabatte vermutlich gar nicht nutzen; jetzt erzielen wir die Einsparungen mit praktisch null Aufwand", sagt DevOps-Lead Kyâne Pichou. "Wir haben es einfach aktiviert und konnten es danach vergessen – so können wir uns voll auf den Ausbau der weiteren Funktionen der Phenix-Plattform konzentrieren."
Diese 1-Jahres-Rabattsätze können Ihre On-Demand-Compute-Ausgaben drastisch senken. Und weil Flexsave parallel zu Ihren bestehenden Commitments arbeitet, müssen Sie nicht fürchten, bereits erzielte Rabatte zu verlieren. Viele DoiT-Kunden kaufen daher weiterhin 3-Jahres-Commitments für einen Teil ihres Compute-Bedarfs, um die Einsparungen zu maximieren, und lassen den Rest von Flexsave mit dem 1-Jahres-Äquivalent abdecken.
Wie die übrigen Produkte und Services von DoiT ist auch Flexsave kostenlos und lässt sich schnell und unkompliziert einrichten – ohne Code-Änderungen und ohne Downtime in Ihrer Umgebung.
Wenn Sie mehr über Flexsave oder andere von DoiT empfohlene Strategien zur Cloud-Kostenoptimierung erfahren möchten, sprechen Sie noch heute mit einem unserer Experten.