Cloud Computing spaltet sich derzeit in zwei Lager. Die Liebhaber eines geschlossenen, proprietären Systems und die Befürworter einer offenen (Open-Source) Cloud. Interessanterweise stellen verstärkt die Open-Source Jünger, allen voran das OpenStack Projekt die größten Lautsprecher dar (Rackspace: Linux der Cloud). Sei es auch nur, um mehr Aufmerksamkeit von den derzeit erfolgreichen geschlossenen Systemen (Amazon Web Services (AWS), Microsoft Windows Azure) auf sich zu lenken. Eines vorweg, pauschal lässt sich nicht sagen, welcher Ansatz der “Bessere” ist. Es hängt immer von den eigenen Anforderungen und Möglichkeiten ab. Zudem sollte man schauen, wie geschlossen die proprietären Systeme wirklich sind. Man wird zum einen merken, dass viel mehr religiöse Ansichten dahinter stecken als man denkt und das die Argumentation Vendor Lock-in bei Open-Source Clouds nicht zwangsläufig zutrifft. Denn einen Vendor Lock-in hat man immer.
Geschlossene Cloud gleich Lock-in?
Hauptargumentation aus dem Open-Source Lager gegen proprietare Cloud Angebote ist das Risiko eines Lock-in. Um diesen zu umgehen, solle man stattdessen auf Angebote setzen, die auf Open-Source basieren, um sich über eine eigene Private Cloud die Freiheit zu verschaffen, also die Infrastruktur und Daten dann ggf. in die eigene Cloud zu transferieren.
Eines sollte man jedoch nicht vergessen, ohne Open-Source funktioniert derzeit so gut wie kein Cloud Angebot. So besteht die AWS Cloud aus wahrscheinlich der größten XEN (Hypervisor) Installation weltweit. Zudem wird argumentiert, dass mann sich bei AWS in einen Lock-in begibt. Bei der DynamoDB mag dies richtig sein. Aber für alle anderen Services gibt es Lösungen wie Eucalyptus, openQRM oder sogar OpenStack selbst, die entsprechende Schnittstellen bereitstellen. Und auch Microsoft ermöglicht es, zwischen Windows Azure und einer auf Microsoft basierenden Private Cloud mit dem Microsoft Server 2012 und dem System Center 2012 Daten usw. hin und her zu schieben. Man ist hier also auch nicht zwangsläufig auf die Public Cloud angewiesen.
Wo versteckt sich der Lock-in?
Ein Vendor Lockin besteht dann, wenn ein System, Angebot oder Lösung sehr stark abhängig macht.
Ein analoges Beispiel dafür ist Ikea. Das Design der Möbel ist so markant, dass es für einen Innenarchitekten Laien (wie mich) schwierig ist, es mit einem anderen Design zu kombinieren. Also geht man dazu über, weitere Möbel bei Ikea zukaufen. Zudem verfügt Ikea über eigene Maße und proprietäre Techniken z.B. bei den Waschbecken oder auch bei den Küchen, Schrauben und sonstigen Verbindungen.
Das Risiko des Lock-ins in der Cloud befindet sich hauptsächlich bei den Daten und Prozessen, wenn diese dort ebenfalls abgebildet werden. Denn in beiden Fällen befinden sich hier die geschäftskritischen Bereiche, die so beweglich wie möglich in der Cloud liegen sollten.
Die Ressourcen wie virtuelle Maschinen sind nicht, wie möglicherweise vermutet, von dem Lock-in betroffen. Hierzu existieren bereits diverse Import/ Export Tools z.B. von VMware für AWS oder speziell V2V (Virtual to Virtual) oder V2P (Virtual to Physical) Mechanismen von openQRM. Das bedeutet, das sich virtuelle Maschinen und deren Inhalte bequem hin und her schieben lassen.
Die Daten selbst sind in der Cloud in der Regel ebenfalls nicht von einem Lock-in betroffen. Die meisten Anbieter verfügen über entsprechende Schnittstellen, über die sich die Daten bewegen und transferieren lassen. Bei den Prozessen wird es schon schwieriger. Aber, wie viele Unternehmen haben in der Vergangenheit ihre Prozesse in die Hände von SAP Systemen gelegt und damit einen Lock-in verursacht?
Ein Lock-in ist nichts Schlechtes
Ein Lock-in, wenn er denn vorliegt, muss nicht immer etwas Schlechtes sein. Im Gegenteil, er führt zu Innovationen und verringert die Komplexität. Der Anbieter nimmt einem beim Design und der Auswahl Stückweit die Entscheidung ab und sorgt für eine stetige Weiterentwicklung und Verbesserung des Systems.
Zudem sollte man schauen, wer sich einen Lock-in nicht leisten kann. Kleine und mittelständische unternehmen, die ggf. über eine kleine oder keine IT-Abteilung verfügen, nehmen das gerne in Kauf, da sie sich die Implementation einer komplexen Umgebung nicht leisten können bzw. nicht über die Expertise verfügen. Analoges Beispiel, Ikea: Man bekommt relativ günstig gute Möbel und kann alles miteinander gut kombinieren.
Außerdem, schaut man sich Open-Source Projekte wie OpenStack an, wird deutlich, dass es nicht immer einfach ist, alle Interessen unter einen Hut zu bekommen. Open-Source mag zwar offen sein. Auf Grund der vielen beteiligten Unternehmen können so manche Konflikte den Innovationsgrad jedoch verringern. Aus diesem Grund kann ein Vorteil darin bestehen, wenn nur ein Unternehmen an der Spitze des Projekts/ Angebots steht und die Koordination übernimmt. Auch wenn mehrere Teilnehmer mehr Input und Expertise liefern. Hier haben auch geschlossene Anbieter einen Vorteil, da sie alleine verantwortlich sind, und damit schneller handeln. Das kann im Umkehrschluss bedeuten, dass der Lock-in von OpenStack in den potentiellen Konflikten und dem daraus folgenden langsamen Innovationsgrad besteht.
APIs sind entscheidend
Wichtig für jedes Cloud Computing Angebot sind die APIs. Auf diese muss sowohl von Innen als auch von Außen zugegriffen werden können, um auf dieser Basis die Daten in aus der Cloud zu transferieren.
Vorteile vs. Nachteile von Open-Source
Open-Source Cloud-Implementierungen gibt es erst seit ein paar Jahren und haben bis jetzt noch nicht ausreichend Anwendungsfälle im produktiven Betrieb. Obwohl eine Reihe von Early-Adoptern aus dem Telkosektor, Finanzdienstleister und wissenschaftliche Einrichtungen bereits Alternativen in Open-Source Cloud Systeme suchen, ist die Vielzahl an Unternehmen darüber nicht informiert. Es lohnt sich daher mal einen Blick auf die Vor- und Nachteile zu werfen.
Vorteil: Flexibilität
Per Definition bieten Open-Source Clouds ein höheres Maß an Flexibilität als der proprietäre Mitbewerb. Statt sich einfach nur mit dem Lesen von Anleitungen zufrieden zugeben oder an Schulungen teilzunehmen, können Nutzer selbst Änderungen an dem Code vornehmen und sich selbst mit eigenem Code an verschiedenen Projekten beteiligen. Zudem können sie eigene Projekte starten, eigene Dokus zur Verfügung stellen oder Seminare abhalten. Interaktionen mit der Gemeinschaft und der damit verbundenen Weiterbildung ermöglichen dem Anwender mehr Flexibilität bei der Gestaltung ihres Cloud-Designs und fördert innovative interne oder externe Lösungen.
Vorteil: Vendor Lock-In
Ein Argumente der Open-Source Cloud Community ist die Prävention vor einem Vendor Lock-in. Die Argumente sind einfach. Wird eine Cloud auf Basis einer offenen und weit verbreiteten Open-Source Technologien aufgebaut, hat kein Anbieter die Möglichkeit die volle Kontrolle über das Open-Source Framework zu erhalten. Damit können Anwender schneller auf die Entwicklung der Technologien im Rahmen des Open-Cloud Stacks reagieren. Darüber hinaus geben Open-Source Clouds dem Nutzer die Freiheit, seine Cloud an seine individuellen Bedürfnisse und Unternehmensziele anzupassen, statt diese anhand einer einzigen proprietäre Lösung aufzubauen.
Vorteil: Einsparung
Open-Source Software ermöglicht auf Grund seiner Lizenzierung die kostenlose Nutzung und hat damit preislich einen enormen Vorteil gegenüber dem kommerziellen Mitbewerb. Egal ob sich ein Nutzer nun für ein reines Open-Source Angebot oder für eine kommerzielle Open-Source Lösung entscheidet, wird er im Vergleich zu einer proprietären Software Kosten sparen können. In jedem Fall besteht für jedes Unternehmen die Möglichkeit, durch Open-Source Software, bei gleichzeitiger Erhöhung der Flexibilität, die Kosten zu senken, was einen Gewinn für jede Organisation darstellt.
Vorteil: Kontrolle, Offene Standards, APIs
Eine Open-Source Cloud setzt auf offene Standards und APIs und wird nicht von einem einzigen Hersteller kontrolliert. Das erlaubt es Unternehmen, die Kontrolle über die darunter liegende Hardware Infrastruktur und Managementplattform zu behalten, unabhängig davon, um welche Technologie es sich handelt. Des Weiteren ermöglichen offene APIs eine bessere Integration in bestehende offene oder proprietäre Lösungen, womit sichergestellt wird, dass aktuelle IT-Investitionen innerhalb der neuen Architektur weiterhin relevant sind.
Vorteil: Portabilität
Baut man seine Cloud auf Basis von Open-Source auf, sollte man immer schauen, wie es mit der Interoperabilität zu anderen Public, Private oder Hybrid Cloud Lösungen ausschaut. Entscheidet man sich für eine offene Technologie erhält man damit ein höheres Maß an Portabilität innerhalb des großen Cloud Ökosystems. Anstatt ihre eigenen Möglichkeiten auf proprietäre Technologien zu beschränken, können sich Nutzer an unterschiedlichen Open-Source Cloud Technologien bedienen und damit ihre IT-Entscheidungen unterstreichen und die eigenen Bedürfnisse und Unternehmensziele damit unterstützen.
Nachteil: Mangel an Unterstützung
Anwender die sich dafür entscheiden, ihre Cloud auf reiner Open-Source Software aufzubauen, begeben sich bzgl. Support in die Abhängigkeit des Open-Source Projekts. Das kann ganz schön zäh und schmerzhaft werden. Denn der Support kommt hier anhand von Foren, Chats, Q&A Systemen und Bug-Tracking Systemen von der Crowd. Zudem sollte man sich als Nutzer aktiv in der Community beteiligen und etwas dazu beitragen, was in der Welt der kommerziellen Software nicht notwendig ist. Auf der anderen Seite kann man sich für kommerzielle Open-Source Cloud Lösungen entscheiden, die für professionellen Support sorgen.
Nachteil: Kosten
Zwar haben Open-Source Lösungen auf Grund der in der Regel kostenlosen Lizenzen, im Vergleich zu kommerzieller Software, einen Kostenvorteil, allerdings gibt es auch hier Kosten die nicht zu vernachlässigen sind. Zum einen wird für den Aufbau einer Open-Source Cloud ein nicht zu unterschätzendes Wissen für die Entwicklung benötigt. Zum anderen müssen auch die Administratoren für einen einwandfreien Betrieb der Infrastruktur sorgen, wofür intensive Kenntnisse für die Verwaltung und Wartung der Lösung erforderlich sind. Darüber hinaus wird externes Fachwissen in Form von Beratung oder Entwicklung-Ressourcen benötigt.
Nachteil: Reifegrad
Je schneller sich das Open-Source Cloud Ökosystem entwickelt, kann sich ein Anwender nicht zwangsläufig darauf verlassen, das und wie lange ein Open-Source Projekt bestand hat. Wenn sich ein Cloud Architekt während des Designs einer Open-Source heute für eine bestimmte Technologie entscheidet, kann es durchaus passieren, das ihn diese in Zukunft einholen wird, da das Projekt eingestellt und nicht mehr weiterentwickelt wird. Mit den stetig steigenden Open-Source Projekten und unterschiedlichen Ansichten ist es für den Anwender zunehmend schwieriger geworden sich für den “richtigen” Weg zu entscheiden.
Fazit
Verantwortliche die sich für eine Cloud Infrastruktur entscheiden, wollen diese hochverfügbar, einfach zu bedienen und so agil, dass sie sich mit den Bedürfnissen der Unternehmensziele verändert. Es ist daher entscheidend, dass sich ein Entscheider zunächst über die Unternehmensziele im klaren ist und sich mit seiner bestehenden IT-Infrastruktur auseinandersetzt, bevor er über eine Open-Source oder proprietären Cloud Infrastruktur nachdenkt. Möglicherweise kann man auch zu dem Ergebnis kommen, dass eine Open-Source Cloud für das Unternehmen keinen nennenswerten Vorteil bietet und eine proprietäre Cloud besser für den eigenen Innovationsgrad ist oder auch andere Möglichkeiten evaluiert werden müssen.
