Blinder Fleck im Cloud-Himmel

In den letzten Jahren hat sich in Sachen Cloud-Governance einiges getan. IT-Teams sind oftmals zu einem aktiven Management ihrer Cloud-Anwendungen und -Anbieter übergegangen, um nicht – wie in den Anfangszeiten der Cloud – von einer Welle einzelner Abrechnungen unterschiedlicher Dienste überschwemmt zu werden. Die Optimierung von Public-Cloud-Ausgaben gilt weiterhin als eine der wichtigsten Initiativen für Unternehmen wie der Report „Rightscale 2018 State of the Cloud“ zum zweiten Mal in Folge bestätigt.

Trotz aller Umsicht ist das Kostenkonstrukt für lizenzierte Software, die auf Public-Cloud-Instanzen läuft, für viele Unternehmen jedoch immer noch ein blinder Fleck auf der IT-Landkarte. In einigen Fällen können die Kosten der lizenzierten Software die Kosten der Cloud-Infrastruktur, auf der sie läuft, bei weitem übersteigen. Die Entwicklung der Cloud zu einem Hub für Anwendungen, die mit Edge-Geräten für Mobile und dem Internet of Things (IoT) verbunden sind, tut dazu sein Übriges. Auch Edge-Geräte können lizenzierte Software-Komponenten beinhalten, die die Gesamtkosten eines Dienstes weiter in die Höhe treiben. Fehlt ein vollständiges Bild der Kosten aller Cloud-Workloads, einschließlich Software-Lizenzkosten, riskieren Unternehmen so, in gleich mehrere Kostenfallen zu tappen.

Von Anbieter zu Anbieter verschieden

Zu hohe Cloud-Lizenzkosten können unterschiedliche Gründe haben: Für einige Workloads nutzen Unternehmen PaaS-Diensten (z.B. Database-as-a-Service oder Hadoop-as-a-Service). Häufig werden parallel lizenzierte Anwendungen auf Cloud-Instanzen installiert. Diese Lizenzen sind in manchen Fällen durch bestehende Unternehmensverträge abgedeckt. Oft jedoch stellen sie Netto-Neulizenzen dar, die erst noch erworben werden müssen.

Zudem unterscheidet sich die Preispolitik für Software-Lizenzen für Public-Cloud-Instanzen von Anbieter zu Anbieter oft grundlegend. Eine in der Public Cloud laufende Anwendung kann teurer oder günstiger sein als bei vergleichbaren On-Premise-Lösungen – selbst bei gleich großen virtuellen Maschinen und gleichem CPU/Chipsatz. Darüber hinaus werben Anbieter oft mit Vorteilen, wenn die Software in der eigenen Public Cloud des Anbieters betrieben wird. All diese Faktoren sollten berücksichtigt werden, unabhängig davon, ob Unternehmen bestehende Workloads in die Cloud migrieren, in Vertragsverhandlungen stehen, über Preise verhandeln wollen oder gänzlich neue Cloud-Anwendungen entwickeln und sich damit in unbekannte Gewässer begeben.

An zwei Beispielen lässt sich gut veranschaulichen, wie wichtig es für Unternehmen ist, die Lizenzkosten für Cloud-Anwendungen im Auge zu behalten.

Beispiel 1: Lizenzierung der Oracle Database Enterprise Edition

Oracle weist CPU-Kerne auf lizenzierte Prozessoren unterschiedlich zu, je nachdem ob es sich On-Premise- oder Cloud-Computing-Umgebungen handelt. Die Folge: Die Software-Lizenzkosten für Oracle Database Enterprise Edition sind in AWS oder Azure doppelt so hoch wie bei On-Premise-Implementierungen. Damit versucht Oracle Kunden dazu zu bewegen, entweder die eigene Oracle-Cloud zu nutzen oder bei On-Premise-Angeboten zu bleiben.

Wer trotz dieser Preisgestaltung die Oracle-Datenbank auf AWS- und Azure-Cloud nutzen möchte, sollte folgende Optionen berücksichtigen.

• Anpassung einer Instanz: Man sollte sicherstellen, dass vCPUs in der Cloud nicht überdimensioniert sind. Welche Faktoren schränken die Performance ein? Liegt es am Speicher, können Instanzen mit einer optimalen Relation von Memory vs. vCPU ausgewählt werden, z. B. AWS X1-Instanzen oder Azure G-Serie oder M-Serie Instanzen.
• Beschränken von zugeteilten vCPUs: Ist die richtige Instanzgröße gewählt, lässt sich die Anzahl der vCPUs festlegen, um Kosten besser zu steuern. Optionen von AWS Optimize CPU und Azure Constrained CPU ermöglichen es, vCPUs reduzieren und Softwarelizenzkosten zu senken.
• Möglichkeiten von Database-as-a-Service: In manchen Fällen kann es sinnvoll sein, auf andere Database-as-a-Service-Angebote (DBaaS) auszuweichen, die den jeweiligen Anforderungen optimal entsprechen. AWS und Azure bieten beide mehrere SQL-Database Engines an, darunter MySQL, MariaDB und PostgreSQL mit ihren jeweiligen eigenen proprietären Angeboten.

Beispiel 2: Azure Hybrid Benefit (AHB)

Microsoft erlaubt es, ungenutzte Lizenzen für Windows Server oder SQL Server auf Azure-Instanzen anzuwenden. Damit lassen sich bereits erworbene Software-Lizenzen sinnvoll einsetzen und die Stundenpauschale bei Azure-Instanzen senken.

Azure-Anwender sollten diesen Azure Hybrid-Vorteil in ihrer Planung berücksichtigen, um letztlich ihre Microsoft-Ausgaben zu optimieren. Hilfreich sind folgende Richtlinien:

• Prüfen von Microsoft-Lizenzposition: Für Windows Server Datacenter Edition kann jede Lizenz zweimalig verwendet werden – On-Premise und gleichzeitig auf Azure. Für Windows Server Standard Edition lassen sich ungenutzte Windows-Server-Lizenzen verwenden, die für Azure neu zugeteilt werden.
• Achtung vCPUs: Jede Zwei-Prozessorlizenz für Windows Server entspricht zwei Azure-Instanzen mit bis zu acht Kernen oder eine Instanz mit bis zu 16 Kernen. Um dies voll ausschöpfen zu können, empfiehlt sich nach Möglichkeit die Anwendung von AHB auf Instanzen mit acht oder 16 Kernen.
• Implementieren von kontinuierlicher Lizenzoptimierung: AHB ist keine einmalige Angelegenheit. Vielmehr sind Lösungen nötig, mit denen die IT-Abteilung die verwendeten Lizenzen sowohl On-Premise als auch in der Cloud kontinuierlich kontrollieren kann. So wird sichergestellt, dass Unternehmen nicht mehr kaufen als sie tatsächlich benötigen. Steigt die Lizenznutzung On-Premise, müssen die für AHB in Azure zugewiesenen Lizenzen freigeben werden. Azure-VMs können dann zu On-Demand-Kosten für Windows genutzt werden. Ein solcher flexibler Ansatz vereinfacht es den Unternehmen, die Nutzung ihrer Lizenzen zu optimieren und gleichzeitig die Compliance einzuhalten.

* Der Autor Thomas Reiber ist Regional Vice President DACH bei Flexera.

Bildquellen: Thinkstock/iStock, Flexera