Welche Schnittstellen taugen für das Open Cloud Computing?

Abstraktionsmodelle und Kompatibilitäts-Layer für Cloud-APIs

| Autor / Redakteur: Thomas Drilling / Ulrike Ostler

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)

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.

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.

Inhalt des Artikels:

Was meinen Sie zu diesem Thema?

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 42234215 / Hardware)