Standards für Cloud Computing: Traum und Wirklichkeit

Original Artikel von Justin Foster (Software Architect bei Trend Micro)

Portabilität und Interoperabilität beim Cloud Computing scheinen die Sicherheit nur marginal zu berühren. Doch sind die beiden Bereiche wichtig, wenn es darum geht, die Abhängigkeit von einem einzigen Anbieter zu vermeiden, um etwa Risiken bei der Verfügbarkeit von Diensten und Daten möglichst gering zu halten. Standardisierung war schon immer ein Mittel, um Portabilität und Interoperabilität sicher zu stellen. Daher ist es nicht weiter verwunderlich, dass man auch beim Cloud Computing davon ausgeht, über Standards Herstellerabhängigkeit vermeiden zu können.

Interoperabilität und Portabilität für Infrastructure-as-a-Service (IaaS) wirft zwei wichtige Probleme auf. Das eine ist das Format der Templates (oder Images) der virtuellen Maschine für die Beschreibung der Platten und der Konfiguration der erforderlichen virtuellen Ressourcen. Im Allgemeinen werden diese Daten von der darunter eingesetzten Virtualisierungslösung bestimmt, doch haben einige Anbieter eigene Formate entwickelt, beispielsweise die Amazon Machine Image. Zwar gibt es das Open Virtualization Format (OVF) als einzigen Standard, doch werden Anbieter öffentlicher Clouds aus verschiedenen Gründen auch weiterhin ihre eigenen Formate unterstützen. Daher bietet sich als zweitbeste Lösung für die praktische Portabilität eine Formatumwandlung an. Als Zwischenlösung akzeptieren einige Service Provider mittlerweile mehrere Formate, um den Umwandlungs-Overhead zu vermeiden.

Die zweite Herausforderung besteht in der derzeitigen Inkompatibilität des Management-APIs für das Hoch- und Herunterladen, die Inspektion, Konfiguration sowie verschiedene andere Aktionen. Jeder Anbieter hat sein eigenes API, das Orchestrierungs-Software daran hindert, mit mehreren Service Providern zusammen zu arbeiten. Mehrere Ansätze für eine Problemlösung sind vorhanden. Einige Gruppen wie das Open Grid Forum versuchen, mit dem Open Cloud Computing Interface (OCCI) einen Standard zu spezifizieren. Andere wie Eucalyptus emulieren das Amazon Web Services Interface als den Defacto-Standard. VMware hat sein eigenes vCloud API entwickelt und dies der Distributed Management Task Force (DMTF) als offenen Standard übergeben. Das vCloud API soll eine Basisinteroperabilität zwischen Vmware-basierten Lösungen (und künftig vielleicht auch anderen) liefern. Dabei geht es aber bestimmt nicht um die etablierten Lösungsanbieter.

Die meisten Provider verzichten auf offizielle Standardisierung, weil sie in diesem aufstrebenden Markt schnell vorankommen wollen und müssen, und Standardisierungsgremien sind nicht gerade für ihre Schnelligkeit bekannt. Doch auch wenn es nicht ein einziges, allgemein akzeptiertes API gibt, heißt das nicht, dass diese Tatsache die Interoperabilität und Portaliblitä zunichte macht. Mehrere APIs lassen sich unter einem einzigen kombinieren, auch ohne Zutun des Providers.

Für den Bereich Virtualisierung gibt es bereits ein API für die APIs, und zwar ist das das libvirt.  Für das Cloud Computing übernimmt das Unified Cloud Interface Project die Aufgabe, ein solches API zu definieren, die Arbeiten stecken allerdings noch in den Kinderschuhen. Eine weitere Initiative cloudloop liefert ein API für die Zusammenarbeit verschiedener Storage-Dienste, sodass Framework-Anbieter, Middleware-Hersteller und Endanwender ein einziges API nutzen können, ohne sich über die Abhängigkeit von einem Service Provider Gedanken machen zu müssen.

Für Platform-as-a-Service (PaaS) wiederum stellt Portabilität und Interoperabilität eine größere Herausforderung dar, denn Plattform-Dienste können naturgemäß sehr verschiedene Datenformate umfassen. Windows Azure beispielsweise bietet Datenbank-Services und .NET-Anwendungs-Container. Die Applikationen und Daten in Azure aber sind nicht kompatibel zur Google AppEngine. Die einzige Möglichkeit, eine Abhängigkeit zu verhindern, wenn PaaS eingesetzt wird, ist folglich, ein Framework zu wählen, das mehrere Provider offerieren sowie Provider-spezifische Erweiterungen wie die von Python in AppEngine zu vermeiden. Ich gehe davon aus, dass eine ähnliche Abstraktionsstrategie wie in anderen Cloud-Bereichenentstehen wird, sodass eine Anwendung auf vielen PaaS-Produkten lauffähig sein wird.

Die größten Interoperabilitätsprobleme hat aufgrund der Datenvielfalt im Internet Software-as-a-Service (SaaS). Man kann nicht erwarten, dass Daten von Facebook in andere soziale Medien-Site exportiert und von da importiert werden können. Auch lässt sich nicht davon ausgehen, dass alle Software-Services Datenextraktion anbieten. Im Fall von Services wie Google Docs jedoch, kann man natürlich eine Form der Umwandlung oder Export-Optionen erwarten. Hier ist Umwandlung ein praktischeres Vehikel für die Portabilität als Standardisierung.

In dem sich rapide entwickelnden Markt für Cloud Computing werden viele Standards entstehen. Doch wie schon der Storage-Experte Stephen Foskett bemerkt: „Es werden nur die nützlichen Standards überleben.“ Dies ist ein gesunder Prozess für eine neue Umgebung wie die des Cloud Computings. Bis sich jedoch diese Standards etabliert haben, lässt sich Portabilität und Interoperabilität auch unabhängig davon erreichen – nämlich über Umwandlung und Abstraktion.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

*