Welche Schnittstellen taugen für das Open Cloud Computing? Abstraktionsmodelle und Kompatibilitäts-Layer für Cloud-APIs

Autor / Redakteur: Thomas Drilling / Ulrike Ostler

Die APIs der großen IaaS-Anbieter sind in der Regel zueinander inkompatibel. Das ist aus vielerlei Gründen ärgerlich, etwa für Entwickler und Systemarchitekten. Der Markt hat aber eine Reihe von Projekten, vor Allem aus dem Open-Source-Umfeld, hervorgebracht, die die führenden Cloud-APIs enger zusammenbringen.

Firmen zum Thema

Programmierschnittstellen für das Cloud-Computing eröffnen nicht zwangsläufig Zugang zu wertvollen Inhalten wie ein offenes Buch.
Programmierschnittstellen für das Cloud-Computing eröffnen nicht zwangsläufig Zugang zu wertvollen Inhalten wie ein offenes Buch.
(Bild: saiva-l/Fotolia.com)

Zwar werden die heute existierenden IaaS-Clouds von einer ständig wachsenden Anzahl von Treibern unterstützt, die zum Beispiel mit den Implementierungen von Amazon EC2, Rackspace oder Red Hat kommunizieren. Allerdings birgt bereits das Schreiben einfacher Skripte, ganz zu schweigen von echten Cloud-Management-Anwendungen erhebliche Risiken, etwa wegen etwaiger Abhängigkeiten und der vorhandenen Inkompatibilitäten zwischen den einzelnen APIs.

Obwohl alle Anbieter in irgend einer Form HTTP als RPC-Schnittstelle verwenden, ist zum Beispiel REST keineswegs ein gemeinsamer Nenner unter den etablierten Anbietern. Allein Red Hat und Rackspace verwenden mit OpenStack relativ konsequent REST. Gleiches gilt für Google mit seiner „Compute Engine“. VMware dagegen pflegt sein „vCloud-API“ und Amazons AWS-API „spricht“ unter anderem „SOAP over XML“.

Da das Haupt-Interesse der jeweiligen Anbieter in der Kundenbindung liegt, kann man bei denen nicht unbedingt nach einer Lösung suchen, selbst bei Red Hat mit seiner gebetsmühlenartigen Betonung der Herstellerunabhängigkeit seiner Management-Lösung „Cloud Forms“ nicht. So sind es überwiegend die freien IaaS-Middleware-Lösungen, wie „OpenStack“, „CloudStack“, „OpenNebula“ und „Eucalyptus“, die ihrerseits Schnittstellen zu AWS anbieten, das API des führenden Herstellers.

Die Vorstellung einzelner APIs

Darüber hinaus gehende Lösungen, welche das API-Problem durch eine Art Proxy-Architektur gewissermaßen von der jeweiligen Lösung entkoppeln, finden sich ebenfalls im Open-Source-Lager. Bei der Apache Foundation sind zum Beispeil mit „libcloud“ und dem von Red Hat initiierten „Deltacloud“ gleich zwei Open-Source-Lösungen als Top-Level-Projekte beheimatet, die versprechen, den API-Wildwuchs aus Entwicklersicht erträglicher zu machen.

Apache libcloud

Die Python-Bibliothek libcloud ist bereits seit Mitte des Jahres 2011 ein Top-Level-Projekt der Apache Foundation und bietet Entwicklern die Möglichkeit, einen herstellerunabhängigen Zugang zu den gängigen APIs der führenden Cloud-Anbieter herzustellen. Im Idealfall müssen Programmierer dank einer einfachen Programmierschnittstelle ihre Anwendungen nur einmal entwickeln und können Sie dann ohne Bindung an einen speziellen Anbieter verteilen.

Libcloud unterstützt in der gerade erst am 1. Juli veröffentlichten, stabilen Version 0.13.0 Python 2.5 bis 2.7, alle Python-3-Versionen ab 0.7.1, die Python-Distribution PyPy und bringt über 20 Backend-Treiber für diverse Cloud-Plattformen mit, darunter Amazons EC2, Eucalyptus, Rackspace, IBM und GoGrid. Tomaz Muraus von der Apache Foundation hat auf der letztjährigen Cloud Open in San Diego in einer Präsentation unter dem Titel „Avoiding Vendor Lock-in Using Apache Libcloud“ demonstriert, was mit libcloud möglich ist.

Die von der Apache Foundation organisierte Cloud Open 2013 findet in diesem Jahr übrigens vom 16. bis 18. September in New Orleans statt und wird das Thema API-Konformität erneut aus verschiedenen Blickwinkeln beleuchten.

Deltacloud

Ausschau nach geeigneten Cloud-APIs
Ausschau nach geeigneten Cloud-APIs
(Bild: olly/Fotolia.com)
Das zweite Top-Level-Projekt der Apache Foundation Deltacloud wurde bereits im Mai 2010 von Initiator Red Hat in den Incubator der Apache Foundation gegeben und ist seit Februar 2012 ein Top-Level-Projekt. Zeitgleich hatte Red Hat sein Deltacloud-API auch bei der Distributed Management Task Force (DMTF) eingereicht.

Auch Red Hat will mit Deltacloud einem Vendor-Lockin bei Cloud-Technologien entgegen steuern, obwohl oder gerade weil Red Hat selbst eigene Cloud-Lösungen nicht nur als Middleware vermarktet. Deltacloud ist ein Open-Source-API, das die Unterschiede zwischen Cloud-Ressource-Providern und der Ressource-Verwaltung abstrahiert und als Dienst-basiertes REST-API konzipiert. Die Clients kommunizieren hierbei via httpd mit dem Delta-Cloud-Server, der seinerseits mit den einzelnen Cloud-Providern „spricht“.

Im Unterschied zu libcloud, das in Form einer Python-Client-Bibliothek in erster Linie die Interaktion zwischen den Servern der einzelnen Cloud-Betreiber vereinfachen soll, normiert Deltaclouds REST-Schnittstelle das Zusammenspiel zwischen Cloud-Service-Providern und den Ressourcen in den jeweiligen Cloud-Umgebungen. Aktuell ist die Version deltacloud-core 1.1.3 vom April diesen Jahres.

Server und Client-Unterstützung

Die von Deltacloud gebotene REST-Schnittstellen zu den gängigen Cloud-Infrastrukturen unterstützt gegenwärtig die APIs von Amazon (EC2), OpenStack, Rackspace, Eucalyptus, IBM, GoGrid, OpenNebula, Microsoft und „RHEV-M“, die Management-Komponente in „Red Hat Enterprise Virtualization“. Das Projekt stellt neben dem eigentlichen API-Server auch Client-Bibliotheken für diverse Sprachen zur Verfügung.

Seit der Version 1.0 bietet Deltacloud auch ein EC2-Frontend, welches das API von Amazons Elastic Compute Cloud zur Verfügung stellt, so dass sich Anwendungen, die für EC2 geschrieben wurden, mit wenig Aufwand auch auf anderen IaaS-Clouds portieren lassen. Neben diesem und dem Deltacloud-eigenen REST-API stellt Deltacloud noch ein Drittes in Form eines Frontend für das von der Distributed Management Task Force entwickelte Cloud Infrastructure Management Interface zur Verfügung.

Red Hat: Kein eigener Standard

Die Red Hat Management Plattform soll eine zentrale Rolle spielen und unter anderem die Verwaltung hybrider Clouds vereinfachen.
Die Red Hat Management Plattform soll eine zentrale Rolle spielen und unter anderem die Verwaltung hybrider Clouds vereinfachen.
(Red Hat)
Da sich mit Deltacloud IaaS-Lösungen verschiedener Hersteller über ein einheitliches API ansprechen lassen, kann es in der Tat verhindern, dass sich ein anderer De-facto-Standard für Cloud-Services etabliert. Red Hat selbst will mit Deltacloud nach eigener Aussage keinen eigenen Standard durchsetzen.

Scott Crenshaw, im Jahr 2010 noch Vice President und General Manager, Business Cloud bei Red Hat, heute Senior Vice President, Strategy und Chief Marketing, sagte anlässlich der Vorlage der Deltacloud-Spezifikationen bei der DMTF: „Da sich Cloud Computing in den Unternehmen ausweitet, gewinnen auch Interoperabilität und Portabilität zunehmend an Bedeutung. Mit der Deltacloud API, die wir der DMTF vorgelegt haben, stellen wir dieses Niveau an Interoperabilität allen Clouds zur Verfügung. Red Hat unterstützt weiterhin Unternehmen, bereits heute reale Clouds aufzubauen."

CloudForms 1 und OpenStack

Schematische Darstellung von Cloud Forms (Red Hat)
Schematische Darstellung von Cloud Forms (Red Hat)
(Biled. Red Hat)
In dem kommerziellen IaaS-Produkt-Stack von Red Hat spielt seit 2011 Cloud Forms eine zentrale Rolle. Cloud Forms ist eine IaaS-Management-Lösung, die das Erstellen und Verwalten privater und öffentlicher Cloud ermöglicht und Benutzern in einer verwalteten, überwachten und sicheren Art und Weise Rechen-Ressourcen als Self-Service zur Verfügung stellt.

Zwar hat sich Red Hats Cloud-Strategie in den vergangenen 24 Monaten in einer atemberaubenden Geschwindigkeit auf OpenStack verlagert, dennoch spielt Cloud Forms auch in Red Hats aktuellem auf dem diesjährigen Red Hat Summit vorgestellten Cloud-Bundle Red Hat Cloud Infrastructure eine zentrale Rolle. Dieses besteht aus RHEV, RHEL, CloudForms und Red Hat OpenStack, der hauseigenen, in diesen Tagen erstmals offiziell verfügbaren OpenStack-Distribution. Cloud Forms (ManageIQ) war von Anfang an darauf ausgelegt, mehrere Cloud-Ressource-Provider-Definitionen gleichzeitig verwalten zu können, wobei das Produkt in den Versionen 1.0 und 1.1 via Deltacloud mit jedem einzelnen dieser Cloud-Ressource-Provider kommunizierte.

CloudForms 2

Das ist seit Cloud Forms 2.0 nicht mehr so, wie John Hardys Vortrag Red Hat Cloud Forms Roadmap von diesjährigen Red Hat Summit darlegt. Cloud Forms 2.0 ist faktisch ein Re-Branding der durch die Akquisition von ManageIQ in den Besitz von Red Hat gelangten Cloud-Produkte.

Genau genommen handelt es sich bei Cloud Forms 2.0 um die „ManageIQ EVM-Suite“. EVM unterstützt von sich aus die Integration von Technologieanbietern wie Microsoft System Center, NetApp, ServiceNow, CA Technologies, BMC, HP, F5 und bietet ebenfalls ein REST- und SOAP-basierendes Management als Web-Service. Zusammen mit Red Hats kommender OpenStack-Distribution erfüllt CloudForms damit im neuen Produkt Red Hat Cloud Infrastructure ebenfalls sämtliche Anforderungen an die Konzeption herstellerunabhängige Hybrid-Clouds.

Was die Förderung herstellerunabhängiger Clouds angeht, hat sich Red Hats ursprüngliche Deltacloud-Strategie im Zuge der nahezu vollständigen Fokussierung auf CloudForms und OpenStack insofern geändert, dass man an Stelle eines weiteren Engagement in Deltacloud plant, auch CloudForms in naher Zukunft in Open-Source-Projekten aufgehen zu lassen, so Frederik Bijlsma, EMEA Business Unit Manager Cloud bei Red Hat, auf den diesjährigen Summit.

OpenStack als Standard

Was Cloud-Standards angeht verweist Red Hat unter anderem auch darauf, dass es im Cloud-Segment sowohl Standardisierungsbemühungen, als auch eine Reihe von de facto Standards gibt, etwa der „Emerging Standard“ im Bereich Cloud-APIs in Form des OpenStack-Heat-Projekts, der Multi-Tier Applications Deployments für die Cloud beschreibt. Heat stellt neben OpenStacks eigenem REST-API ein „AWS CloudFormation-API“ für OpenStack zur Verfügung, welches das Orchestrieren von Cloud Applikationen über Datei- oder Web-basierte Templates erlaubt. Eine interessante Erläuterung von Heat finden sich in diesen OpenStack-Heat-Slides.

Abhängigkeit verschiebt sich auf Proxy-Maintainer

Zwar sind libcloud, Deltacloud, Cloud Forms/EVM, sowie das OpenStack API (inklusive Heat) technologisch allesamt interessant, unterstützen aber unter anderem auch Hersteller wie Red Hat darin, sowohl potenziellen Nutzern anderer Cloud-Infrastrukturen einen Migrationspfad zu bieten. Sie erleichtern damit auch Bestandskunden das Aufbauen hybrider Cloud unter Einbeziehung von Fremd-APIs.

Aus Entwickler-Sicht stellen die skizzierten Produkte und Methoden in Bezug auf den eingangs skizzierten API-Wildwuchs aber keine nachhaltige Lösung dar und Red Hat, respektive OpenStack sind in Sachen Cloud Computing trotz des derzeitigen Hypes um OpenStack sicher nicht das Zentrum des Cloud-Universums. Das Problem mit libcloud, deltacloud oder CloudForms besteht nämlich darin, dass irgendjemand die gebotenen Adapter zu AWS&Co pflegen und zeitnah auf konzeptionelle Änderungen etwa bei Amazon, Google, Microsoft, VMware & Co reagieren muss.

Der Vorteil für Entwickler, sich nicht an den APIs der einzelnen Hersteller orientieren zu müssen, ist unbestreitbar, solange die Maintainer die Adapter auf dem neusten Stand halten. Langfristig tragfähige Lösungen sind aber auch libcloud und Deltacloud nicht, weil sie der Fragmentierung der gängigen APIs in Wahrheit nicht wirklich entgegenwirken, sondern eher den StatusQuo zementieren beziehungsweise das eigentliche Problem verschleiern.

Das Open Cloud Computing Interface (OCCI)

Mit der OCCI-Schnittstelle lassen sich interoperable Programme für gemeinsame Aufgaben in Cloud-Umgebungen entwickeln, etwa zur Bereitstellung und zur autonomen Skalierung oder zur Überwachung der Anwendungen.
Mit der OCCI-Schnittstelle lassen sich interoperable Programme für gemeinsame Aufgaben in Cloud-Umgebungen entwickeln, etwa zur Bereitstellung und zur autonomen Skalierung oder zur Überwachung der Anwendungen.
(Bild: OCCI WG)
Eine solche könnte jedoch darin liegen, wichtige Funktionen herstellerübergreifend zu standardisieren, wie es sich die Open Cloud Computing Interface Working Group (OCCI-WG) mit dem Open Cloud Computing Interface OCCI zum Ziel setzt. Die OCCI-WG erarbeitet „hoch“ angesiedelte Spezifikationen einer Programmierschnittstelle (API) für das Remote-Management von Cloud-Computing, wie sie Virtualisierungstechnologien voraussetzen.

Mit dieser OCCI-Schnittstelle lassen sich dann interoperable Programme für gemeinsame Aufgaben in Cloud-Umgebungen entwickeln, etwa zur Bereitstellung und zur autonomen Skalierung oder zur Überwachung der Anwendungen. OCCI bedient neben „Infrastructure as a Service“ (IaaS) auch die Cloud-Computing-Bereiche „Platform as a Service“ (PaaS) und „Software as a Service“ (SaaS).

Am weitesten fortgeschritten ist derzeit die OCCI-Komponente für das Management von Rechenkapazität für die einzelnen Cloud-Implementierungen. OCCI übernimmt dabei die Rolle eines Gateways zur Infrastruktur des jeweiligen Anbieters.

OCCI bekommt Empfehlung

OCCI ist abgesehen von einer einheitlichen Core-Komponente modular aufgebaut, um auch eine auf höherer Ebene angesiedelte Automatisierung über ein und dieselbe Schnittstelle abbilden zu können. Allerdings liegt der schwarze Peter für ein Durchsetzen von OCCI wieder bei den Cloud-Anbietern, welche eine solche Schnittstelle nutzen und unterstützen müssen.

OCCI übernimmt gleichermaßen die Rolle eines Gateways zur Infrastruktur des jeweiligen Anbieters beziehungsweise Projekts.
OCCI übernimmt gleichermaßen die Rolle eines Gateways zur Infrastruktur des jeweiligen Anbieters beziehungsweise Projekts.
(Bild: OCCI WG)
Jedenfalls hat das Bundesministerium für Wirtschaft und Technologie in seiner Studie Das Normungs- und Standardisierungsumfeld von Cloud Computing OCCI neben OpenStack eine hohe Durchsetzungsfähigkeit bescheinigt. Weitere Informationen zu OCCI finden sich in einem interessanten Vortrag von Sam Johnston von der OCCI-WG oder vom OpenGrid-Forum.

Der Autor:

Thomas Drilling ist freier Autor und bloggt auf Datacenter-Insider.de über Open-Source-Themen für Enterprises: Drillings Open-Source-Eck.

(ID:42234215)