Das Reinheitsgebot und die Wolke

Google hat immer wieder das Talent, mächtig Staub aufzuwirbeln, selbst wenn es sich um ein Thema handelt, das von anderen längst schon bearbeitet wurde. Da aber alles, wo Google drauf steht, das Interesse der Menschen fast magisch anzieht, sorgte die Ankündigung der Google App Engine for Java, kurz GAE/J, für mächtig Gesprächsstoff. Vor etwa einem Jahr mit reiner Python-Unterstützung gestartet, steht GAE/J seit Anfang April für 10 000 Betatester zur Verfügung und verspricht problemlose und grenzenlose Virtualisierung.

Weil Google aber bei seinem ersten großen Java-Projekt, dem Handy-Betriebssystem Android, wenig Interesse an echter Java-Kompatibilität zeigte (Android basiert auf einem Dalvik genannten Bytecode, der mit dem Original-Bytecode von Java nur entfernt verwandt ist), war natürlich auch bei GAE/J Skepsis angebracht.

Nein, alles reinstes Java, wurde der Gemeinde beteuert. Allein schon die Tatsache, dass das Suffix „for Java“ explizit benutzt wurde, deutete darauf hin, dass nun wirklich Java-treu implementiert wurde – andernfalls hätten die Sun-Rechtsanwälte (sofern sie gerade nicht alle Hände voll mit Merger-und-Akquisitions-Problemen zu tun haben) das ja gar nicht durchgehen lassen (siehe auch meine Bemerkungen zur Bedeutung der Trademarks im letzten Editorial).

Mittlerweile braut sich aber Unmut zusammen: Simon Phipps, Chief Open Source Officer von Sun, wettert gegen die Google App Engine, die das „for Java“ nicht verdient habe, weil sie allenfalls ein Subset von Java unterstütze:

„Die Java-Kompatibilität hat uns ein ganzes Jahrzehnt lang wichtige Dienste erwiesen (...) Das Erstellen von Subsets von Java-Core-Klassen war immer aus sehr guten Gründen unzulässig, und es ist fahrlässig und verantwortungslos, die Regeln zu brechen.“

Und richtig – die offizielle JRE White List von Google zeigt zwar, was alles geht, sagt aber nicht explizit, was alles nicht geht. Da sich Google nur für Java-Webanwendungen interessiert, gibt es z.B. keinen Support für Swing oder AWT ... die gehören aber dazu, wenn man „Java“ sagt.

Von einem Fork zu sprechen, scheint dagegen überzogen. Haben die, die da schäumen, vergessen, dass man gerade dabei ist, aus den aufgeblähten Java-Editionen spezielle Profile zu bilden, so zum Beispiel eines für reine Webanwendungen? Liebe Leute von Sun, holt einfach die Google- und Amazon-Web-Services-Teams an einen Tisch und redet mit ihnen darüber, wie ein „Java Cloud Profile“ aussehen sollte!

Die Idee, das Thema Hardware und Basisinfrastruktur im Sinne des Cloud Computings zu organisieren, wird sich indes ohne Zweifel durchsetzen. Bis dahin ist aber noch ein steiniger Weg zu gehen. Noch existiert kein Konsens, wie viel und in welcher Weise z.B. Java unterstützt werden soll, noch haben sich die Cloud-Anbieter nicht auf gemeinsame Standards geeinigt, um größtmögliche Kompatibilität zu erzielen.

Die Cloud-Revolution steht gerade erst am Anfang und es konkurrieren vor allem hochproprietäre Angebote um die Gunst der Kunden. Die aktuelle Marktsituation erinnert indes stark an die frühe Zeit der Applikationsserver. Noch bevor EJB 1.0 verabschiedet wurde, boten Symantec, Silverstream oder Borland ihre eigenen Java-basierenden, aber proprietären Systeme an, die sich zwar nicht durchsetzen konnten, jedoch den Weg zu einer Standardisierung bereiteten. Die große Gruppe an Unternehmen, die sich jetzt dem Open Cloud Manifesto (siehe auch Seite 8) angeschlossen haben, haben sich dieses Ziel auf die Fahnen geschrieben.

Wenn die Cloud-Angebote von Google, IBM, Amazon & Co. hinreichend transparent werden – und zwar sowohl in technischer als auch in kostenmäßiger Hinsicht, dann steht dem Erfolg der großen Wolke nichts entgegen. Ob damit traditionelle Rechenzentren oder Hoster von der Bildfläche verschwinden werden – man weiß es (noch) nicht.

Welche rechtlichen Konsequenzen es außerdem hat, wenn z.B. ein deutsches Unternehmen seine Unternehmensdaten auf den Servern eines amerikanischen Anbieters speichert und dessen Rechenzentrum möglicherweise noch auf dem Territorium eines Drittlandes aufgestellt sind ... dies muss sicherlich noch geklärt werden und gehört womöglich zu den größten Hürden für die Akzeptanz des wolkigen Computings.

Sebastian Meyen
Chefredakteur