Nachdem es mittlerweile klar ist, dass viele Infrastructure as a Service als das Synonym für das „eigentliche“ Cloud Computing ansehen (und dabei die interessanten Varianten SaaS und PaaS ignorieren), muss man sich mit einigen Besonderheiten dieses Modells vertraut machen.
Zunächst vereinfacht ausgedrückt: Man hat einen virtuellen Rechner mit bestimmten zugesicherten Eigentschaften. Man hat nicht die geringste Ahnung, was für einen CPU-Typ man unter der Virtualisierungsschicht findet, ja man weiss nicht mal, was für eine Virtualisierungsschicht da als Basis für die eigene Maschine dient. Je nach „Verbrauch“ wird abgerechnet, fertig.
Gut, auf solch einer virtuellen Kiste setzt man seien Webshop auf und stellt sich dann die Frage:
„Wie viele Oracle-10g-Enterprise-Edition- oder Standard-Edition-Lizenzen braucht diese Maschine (1) und ist das ganze supportet(2)?“
Zu Frage 1: Keine Ahnung. Fragen Sie Ihren Oracle-Software-Vertriebsbeauftragten. Dessen normales Berechnungsmodell mit CPUs, Sockeln und Cores samt zugehörigen Core-Faktoren läuft ins Leere. Wenn er keine Lösung findet, können sie den virtuellen Rechner nicht mit einer Lizenz ausstatten.
Zu Frage 2: Aller Wahrscheinlichkeit ist das Ganze unsupported: Oracle lässt nur seine eigene OracleVM sowie Solaris Container als Virtualisierungstechnologie zu. Bei anderen Virtualisierungslösungen gibt’s keinen Support oder man behält sich das Recht vor, dass der Fehler auf nicht-virtualisierter Hardware reproduziert werden muss.
Vor solchen Problemen steht man nicht nur, wenn man die Datenbank von Oracle nutzen möchte. Auf Software wie Mathematik-Programme oder manche Betriebssysteme werden pro CPU oder pro Core lizenziert. Was soll man mit solcher Software in der Cloud machen? Vorsichtshalber für eine 8-Prozessoren-Quadcore-Maschine wie die M4600M2 eine Lizenz erwerben, und hoffen dass der Cloud-Anbieter nicht irgendwo eine 16-CPU-x86-Maschine auftreibt? Oder doch auf eigener Hardware rechnen?
Oder andere Software verwenden, die Cloud-tauglich ist? Aus rechtlicher Perspektive mag dies eine Option sein, doch aus applikatorischer nicht immer.
Zusammenfassend wird es letztlich drei Alternativen geben:
1. Die Softwarehersteller bewegen sich – eine durchaus wahrscheinliche Alternative: Mit speziellen Lizenzangeboten für Cloud Computing, eventuell mit Freigaben für bestimmte IaaS-Produkte, werden sich die Hersteller diesen Markt erschließen können. Vor allem bieten sich dann neue Lizenzmodelle, die sich an den verbrauchsabhängigen Modellen der IaaS-Anbieter orientieren. Eine Datenbank könnte pro Transaktion oder pro verwaltetem Gigabyte berechnet werden, Betriebssysteme nach produktiver Uptime.
2. Die IaaS-Anbieter bewegen sich: Mit zugesicherten maximal zu verfügungstehenden CPUs und Cores, unter zu Hilfenahme von supporteter Virtualisierungstechnologie. Man macht somit die Cloud ein wenig unelastischer, doch lässt man so auch „alte“ Lizenzmodelle zu.
3. IaaS bleibt solchen Anwendungen verschlossen, man bezieht sie als SaaS: Warum selbst die Datenbank betreiben, wenn man sie als Service zukaufen kann? Sofern der Preis in Orndung ist und die Bandbreite ausreicht, wäre auch dieser Schritt denkbar.
Somit bleibt der Markt für Softwarelizenzen im Cloud Computing interessant. Neue Lizenzmodelle werden Software Cloud-tauglich machen und SaaS wird heute noch lokale Software auslagern. Kurzfristig könnte auch die zweite Alternative zum Tragen kommen, langfristig werden Kopplungen an Kerne oder CPUs verschwinden, auch weil Anwender irgendwann gar nicht mehr wahrnehmen können, auf welcher Sorte CPU sie gerade unterwegs sind.