Die Revolution beim Cloud-Computing liegt im Bezugsmodell. Unterschieden werden derzeit »Software as a Service«, »Platform as a Service« und »Infrastructure as a Service«. Im Prinzip technologisch bekannte Mechanismen, aber mit dem Ziel IT-Investitionen in betriebsbedingte Ausgaben umzuwandeln.
Cloud-Architektur der Bitkom.
Im Gegensatz dazu haben sich Cisco und EMC/VMware mit »Virtual Computing Environment« in einer Art Koalition zusammengefunden. Sie wollen »Acadia« durchsetzen und damit den Endkunden die Möglichkeit bieten, schnell auf Cloud-Computing zu setzen. Dies trifft auf die bestehenden Anbieter wie Amazon, Salesforce oder Google zu, die bereits ihre Dienste für viele Anwendungsfelder feilbieten. Zudem sind noch viele IT-Dienstleister wie Computacenter oder Carrier wie etwa BT im Bereich Cloud-Computing aktiv.
Alles eine Frage der Interpretation
Genauer betrachtet verstecken sich hinter dem Schlagwort Cloud-Computing noch viele Interpretationsmöglichkeiten. Für den deutschsprachigen Bereich hat sich der Branchenverband Bitkom an einer Definition versucht, die sich mittlerweile in der Diskussion durchsetzt. Der Leitfaden »Cloud-Computing – Evolution in der Technik, Revolution im Business« stellt den Sachverhalt folgendermaßen dar:
Cloud-Computing ist eine Form der bedarfsgerechten und flexiblen Nutzung von IT-Leistungen. Diese werden in Echtzeit als Service über das Internet bereitgestellt und nach Nutzung abgerechnet. Dies ermögliche den Anwendern eine Umverteilung von Investitions- zu Betriebsaufwand. Die IT-Leistungen können sich auf
- Anwendungen,
- Plattformen für Anwendungsentwicklungen und -Betrieb sowie
- die Basisinfrastruktur beziehen.
Aus dieser Quelle stammt auch die Aussage, dass es für die Auseinandersetzung mit diesem Thema nötig sei, einen klaren Bezug zu den Ebenen von Cloud-Services, den Organisationsformen von Clouds und zur betrachteten Nutzergruppe herzustellen.
Drei Ebenen sind zu unterscheiden
In diesem Zusammenhang hat sich eine Klassifizierung in drei Ebenen durchgesetzt: »Infrastructure as a Service (IaaS)«, »Platform as a Service« (PaaS) sowie »Software as a Service« (SaaS). Dieses Schichtenmodell aus SaaS, PaaS und IaaS bildet den »SPI-Stack«.
Nähert sich der Anwender diesen Schichten von oben, trifft er auf SaaS. Dabei wird eine Applikation wie zum Beispiel ein CRM-System, eine ERP-Software oder auch nur ein Office-Paket in Form von webbasierten Diensten über das Internet bereitgestellt.
In dieser Ausprägung bündelt der Anbieter die Infrastruktur-Ressourcen und die Applikation zu einem Anwendungsservice. Dabei greifen alle Kunden auf dieselbe Anwendung und Infrastruktur eines Anbieters zu. Ein Vorteil dieses Ansatzes, bei dem ein Anbieter eine Vielzahl von Kunden bedienen kann: Alle Aktivitäten der Applikationen müssen nur einmal vorgenommen werden und stehen dann sofort für alle Kunden parat. In bestimmten Fällen begrenzt dabei aber der hohe Grad an Standardisierung die individuelle Anpassbarkeit der Lösung.
Im Fokus: Software-Entwicklung
Auf der Ebene PaaS rangieren Angebote, die sich auf die Software-Erstellung konzentrieren. Damit sind Unternehmen, die Software mit ihrer Geschäfts- oder Anwendungslogik entwickeln, in der Lage, auf diesen Plattformen ihre Applikationen zu entwickeln. Vorteil: Sie müssen sich nicht um die zugehörige IT-Architektur und deren Betrieb kümmern. Das übernimmt der PaaS-Provider. Hier sind Angebote zu nennen, wie sie von Salesforce mit Force.com oder von Google mit »App Engine« bereitstehen. Allerdings sind dabei je nach Plattform verschiedene Einschränkungen zu beachten, etwa welche Programmiersprache unterstützt wird.
Nackte Infrastrukturen vorhalten
Bei den IaaS-Providern handelt es sich um Unternehmen, die sich auf die reinen IT-Infrastrukturen konzentrieren. Dazu zählen virtuelle Rechen- oder Speichereinheiten, wie sie zum Beispiel Amazon mit »Elastic Compute Cloud« (EC2) und »Simple Storage Services« (S3) im Programm hat.
Die Recheneinheiten von »Amazon Web Services« (AWS) basieren auf der Opensource-Virtualisierungslösung »Xen«. Dabei haben Anwender beispielsweise die Möglichkeit, unterschiedliche Ausprägungen von Rechenleistung zu kaufen, die rein nach dem Verbrauch abgerechnet wird.
Im Bezugsmodell liegt die Innovation
Damit diese Zuteilung in Häppchen funktioniert, müssen die entsprechenden Ressourcen – wie etwa die Recheneinheiten – in einem möglichst hoch automatisierten Selbstbedienungsmodell bereitgestellt werden. Das Teilen der Infrastruktur unter verschiedensten Kunden – die durchaus in einem erbitterten Wettbewerb stehen können – muss aber sicherstellen, dass die Daten der einzelnen Bezieher eines Services absolut sicher – also in getrennten Adressräumen und auf entsprechenden Massenspeichern – abgelegt sind. Die Bezieher einer Dienstleistung sehen daher immer nur die Schnittstelle zum Service, nicht aber dessen Implementierung.
Ein wichtiger Aspekt in diesem Zusammenhang ist die Qualität des Dienstes. Je kritischer eine Applikation für den Erfolg eines Unternehmens ist, umso mehr sollte man überlegen, was passiert, wenn dieser Service nicht oder nur mit Einschränkungen (also einer zu geringen Qualität) bereitgestellt wird. Dazu kommt das Thema Service-Level-Agreements (SLA) auf die Agenda (siehe Beitrag).
Wenn sie mit den externen Diensten liebäugeln, scheint es für Unternehmen ratsam, sich auf ein vorsichtiges Herantasten zu beschränken. Auch der Bitkom rät, zunächst anhand von Pilotprojekten erste Erfahrungen mit diesem Bezugsmodell zu machen.
Diese Vorgehensweise begleiten auch die Anbieter von Cloud-Lösungen. Sie versuchen mit Begriffen wie Public-, Private- und Hybrid-Clouds hier verschiedene Szenarien zu unterstützen. Denn das Beziehen von IT-Leistungen allein über einen internen (also die Private-Cloud) oder externen IT-Dienstleister (in einer Public-Cloud) ist nicht immer sinnvoll. Oftmals empfiehlt sich ein gemischter Ansatz – vor allem wenn es darum geht, die älteren Applikationen am Laufen zu halten.
Problemfeld Standardisierung
Derzeit hat sich noch kein Hersteller bzw. keine Allianz als Standard durchgesetzt. Generell stehen Anwender vor dem Problem, dass sie sich in ihren Cloud-Projekten auf die Schnittstellen-Definition eines Anbieters oder einer Allianz einlassen müssen. Wer sich die Programmierschnittstellen (APIs) von Microsoft, Amazon oder Google ansieht, der kann sich vorstellen, wie groß der Aufwand wird, wenn man später zu einem anderen Anbieter wechseln möchte.
Vmware hat seinen Vorschlag für ein Cloud-Betriebssystem in Form des »VCloud-API« beim Normierungsgremium Distributed Management Task Force (DMTF) eingereicht. Damit sollen weitere Unternehmen der Cloud à la Vmware beitreten. Laut eigener Aussage will das Unternehmen damit eine konsistente Mobilität, die Bereitstellung, das Management und die Service-Gewährleistung von Applikationen ermöglichen, die in internen und externen Clouds laufen. Der Azure-Lösung von Microsoft wird künftig viel zugetraut. Derzeit hinkt sie aber hinsichtlich der Funktionalität den etablierten Cloud-Anbietern wie Amazon oder Google hinterher.