When The Power Goes Out at Google

Aber auf den zweiten Blick ist die Cloud doch etwas anders. Denn die Cloud ist garnicht eine Lösung, sondern die Cloud besteht aus vielen verschiedenen Lösungen von vielen verschiedenen Anbietern. Was diese Anbieter, zumindest die meisten davon, allerdings auszeichnet, ist die Tatsache, dass offene Schnittstellen angeboten werden. Diese ermöglichen es die verschiedenen Einzellösungen zu einer Gesamtlösung zu kombinieren.

Dies ist ein Aspekt der meiner Meinung nach oftmals vergessen wird. Gerade im Bereich Cloud Hosting höre ich oft, ja aber was ist wenn ich dieses besondere Version oder jenes besondere Programm benötige. Auf meinem dedizierten Server kann ich das dann installieren. Meine Antwort darauf ist dann, dass wir als Plattformanbieter einen Mittelweg gehen müssen. Wir können nicht jeden speziellen Wunsch erfüllen. Alles hat Vor- und Nachteile und im Gegensatz zu einem dedizierten Server bringt Cloud Hosting Ausfallsicherheit und Skalierbarkeit inklusive.

Aber was ist, wenn ich nunmal eine ganz bestimmte Softwarekomponente benötige, bleibt mir die Cloud dann verschlossen? Nein, ganz sicher nicht. Es kommt dann eben nur auf die richtige Kobination der verschiedenen Lösungen an.

Nochmal am Beispiel Cloud Hosting, nehmen wir an, ich habe eine Webapplikation entwickelt die bestimmte Datein in verschiedenen Formaten annimmt und in ein einheitliches Format umwandelt. Hierfür wird man wahrscheinlich auf eine der vielen Open Source Anwendungen setzen, die solche Aufgaben spielend meistern. Im Fall von Videodateien ist ffmpeg einer der Kandidaten für den Job. Eine Cloud Hosting Lösung selbst muss hier passen. Es ist unwahrscheinlich, dass, insbesondere in einer geteilten Umgebung, ein Anbieter es ermöglicht im Hintergrund Videotranskodierungsprozesse zu starten.

Aber hier kommt die Idee Cloud wieder zum tragen, denn das muss der Anbieter auch nicht. Man hat ja die Möglichkeit die eigentliche Webapplikation kostengünstig, skalierbar und ausfallsicher ohne großen Administrationsaufwand bei einem Cloud Hosting Anbieter zu hosten und für die Videotranskodierung einzelne Amazon EC2 Instanzen zu spawnen. So profitiert man von den Vorteilen beider Lösungen. Die EC2 Instanzen müssten dabei nicht Vollzeit laufen, man kann die Dateien ja auch in Warteschlagen abarbeiten. Das Spawnen einer EC2 Instanz dauert nur einige Minuten. Für ein paar Cent die Stunde kann man dann einen Schwung Dateien umwandeln und die Instanz wieder beenden.

Damit Nutzer nicht zu lange auf das umwandeln warten müssen könnte man verschiedene Strategien anwenden. Z.B könnte man ein Zeitlimit und ein Dateien in der Warteschlange Limit setzen und je nachdem welches zuerst erreicht ist beginnt man mit dem umwandeln.

Das ist nur ein Beispiel. Auch im Bereich Software as a service gibt es unzählige Beispiele. Nehmen wir z.B. Googles Office Anwendungen Google Apps. Hierfür können Erweiterungen geschrieben werden, um die allgemein gehaltenen Office Anwendungen an eigene Anforderungen anzupassen. So ist es z.B. möglich ein CRM System oder ähnliches zu integrieren. Um diese Erweiterung, die zwischen Google Apps und z.B. Sugarcrm sitzt zu hosten kann man dann wiederrum einen weiteren Cloud Anbieter nutzen.

Die Möglichkeiten sind groß. Das Problem dabei ist nur, das ganze wird schnell sehr unübersichtlich. Wer behält den Überblick über all die verschiedenen Anbieter und möglichen Lösungen? Sollte man sich dann für einzelne Lösungen entschieden haben steht man vor dem Problem der Umsetzung und wenn dann mal etwas nicht funktioniert schieben sich die verschiedenen Anbieter munter die Schuld gegenseitig in die Schuhe? Hier können Berater helfen, die gemeinsam mit Kunden dann Projekte umsetzen und ihre Erfahrung und ihren Überblick einbringen um im Dschungel der Anbieter den Weg zu weisen.

Man sieht also, alles hat Vor- und Nachteile. Nichts ist die Lösung für jedes Problem. Aber zumindest das Problem der Schuldzuweisungen lässt sich einfach lösen. Man muss lediglich den richtigen Anbieter auswählen.

Aber auch wenn das wieder ein Problem für sich ist, ist es kein Problem der Cloud. Dieses Problem hat man in jeder Lebenssituation und häufig gleich mehrmals pro Tag.

Ganz ohne Ausfall wird die Umstellung des Datastore verständlicherweise nicht sein. Entwickler die App Engine nutzen finden die geplanten Umstellungszeiten am Ende des Artikels.

Programmieren mit der Google App Engine

In den letzen Tagen ist Google Chrome OS in aller Munde. Auch wenn es vergleichbare Ideen (z.B. Jolicloud) gibt, ist Chrome OS brilliant in seiner Konsequenz. Man nehme einen Kernel, um die Hardware zu betreiben und setze darauf ausschliesslich einen Webbrowser. Alle Anwendungen für dieses Betriebssystem werden dabei als Webapplikationen über das Internet aufgerufen und lediglich mit Hilfe des Browsers angezeigt. Die Vor- und Nachteile dieser Lösung sind bereits ausgiebig an diversen Stellen diskutiert worden, so dass ich hier darauf verweisen kann.

Für mich viel interessanter ist aber die andere Seite. Serverseitig stellen solche Anwendungen ganz neue Anforderungen an eine Hostinglösung. Aber Hostinglösung ist auch das falsche Wort. Was wir eigentlich sagen wollen ist Internet Betriebssystem. Mir ist natürlich bewusst, dass dies der eigentlichen Definition eines Betriebssystems, nämlich der Abstraktion zwischen Hardware und Software widerspricht. Aber von der Wichtigkeit für das Ökosystem ist mir bisher kein besseres Wort eingefallen. Wer einen Vorschlag hat kann ihn mir in den Kommentaren mitteilen.

Wenn der Client im Sinne von Software as a service nur noch die Anzeige übernimmt, müssen alle weiteren Funktionen Serverseitig ausgeführt werden. Nutzt man darüber hinaus noch das http-Protokoll zur Übertragung der Daten entstehen viele Probleme. Diese sind zwar lösbar und größtenteils auch bereits gelöst. Nur muss dies jeder Applikationsbetreiber aufs neue für sich selbst tun.

Das ist ganz sicher nicht die Art wie Microsoft es geschafft hat Windows als die Plattform für Entwickler zu etablieren. Der Erfolg von Windows war, dass man einfach eigene Anwendungen schreiben konnte und diese dann auf einer Vielzahl an Systemen automatisch lauffähig waren. So jedenfalls die Theorie.

Hier schliesst sich dann auch der Kreis und man erkennt die Zusammenhänge zwischen den verschiedenen Google Projekten. Mit Google Chrome OS schafft Google das Client-Betriebssystem. Mit Google App Engine das Server-Betriebssystem auf dem der Serverseitige Teil der Anwendungen läuft und mit den Google Apps (Mail, Docs, Spreadsheets usw.) hat Google bereits die wahrscheinlich meistverwendeten Anwendungen für die eigene Plattform geschaffen.

Aber wollen wir wirklich den gleichen Fehler wie bei Windows nochmal machen? Wollen wir wirklich von einem einzigen Unternehmen abhängig sein. Ganz ohne Alternativen.

Auf Clientseite ist Google dabei sehr offen. Um eine Anwendung für das Google Chrome OS zu schreiben muss diese lediglich auf den etablierten Webstandards basieren. Mit Chrome der auf Webkit basiert gibt es eine relativ standardkonforme Renderingengine und für die Interaktivität setzt man auf Javascript. Hier muss man sich also nicht auf das Chrome OS festlegen.

Ganz anders sieht dies jedoch im Bezug auf die App Engine aus. Um hier Anwendungen entwickeln zu können müssen die verschiedenen Google APIs genutzt werden. Die der App Engine zu Grunde liegenden Programmierparadigmen sind dabei so umfassend, dass es unerlässlich ist sich bei der Entwicklung der Anwendung darauf zu spezialisieren. Dies bietet nicht unerhebliche Vorteile im Bezug auf die Skalierbarkeit der Anwendung, aber der Preis den man dafür zahlen muss ist sehr hoch. Meiner Meinung nach zu hoch. Eine einmal für App Engine entwickelte Software lässt sich nur nach erheblichen Änderungen an Kernkomponenten der Anwendung auf einer anderen Plattform als Google App Engine betreiben. Dieser Lock-In-Effekt stellt eine große Gefahr für Unternehmen dar, die eigene Anwendungen auf der App Engine Plattform entwickeln. Man verliert effektiv jegliche Alternativen, weil mit steigender Komplexität der Anwendung die Änderungen so tiefgreifend sein werden, dass es einer kompletten Neuentwicklung gleich kommt.

Bei den Cloud Plattformen gibt es zwar bereits Alternativen, kompatibel zu einander sind jedenfalls die der großen Konzerne alle nicht. Es ist unmöglich Anwendungen zwischen Windows Azure und Google App Engine hin un her zu bewegen und es würde mich auch sehr wundern, wenn dies jemals möglich wäre.

Deshalb sehe ich die eigentliche Chance für die weitere Innovation im Web in offenen Plattformen zum betreiben der Webapplikation auf Serverseite. Es muss Entwicklern leicht gemacht werden diese Anwendungen zu entwickeln. Nur so kann die Weiterentwicklung des Internet von einem Inhaltemedium hin zur Applikationsplattform wirklich funktionieren.

Wie seht ihr das ganze?

Bildquelle: Flickr cc by dalbera

Die Software ist noch in einem fühen Stadium und mit Version 0.3 wohl auch noch nicht wirklich für den produktiven Einsatz geeignet. Jedenfalls ist das Datenbankschema der Version 0.3 wohl nicht kompatibel zu dem der Version 0.2 und es gibt auch keinen Upgradepfad.

Von daher ist hier wohl erstmal noch vorsicht geboten. Allerdings ist das Projekt sehr vielversprechend und man sollte es definitiv im Auge behalten, wenn man mit Java auf der Google App Engine Plattform entwickelt.

10 things you (probably) didn’t know about App Engine

Vor einiger Zeit hatte ich mal gefragt, warum Google nicht nach dem Vorbild von Amazon die Kraft der eigenen Marke nutzt um die eigenen Kunden zu promoten und ihnen damit einen weiteren Anreiz zu geben Google App Engine zu nutzen. Offensichtlich hat Google meinen Artikel gelesen, zumindest der Crawler hat jedenfalls, und entsprechend reagiert. Das Google Blog berichtet über Erweiterungen der Community zur App Engine. Zwar noch keine Kunden wie Amazon das macht, aber zumindest ein Schritt in die richtige Richtung wie ich finde.

NAP of the Americas

Wer hin und wieder Spaß daran hat Videos von großen Rechenzentren zu sehen hat jetzt die Gelegenheit in eines der größten zu blicken. Ein Werbefilmchen von HP gibt Einblick ins NAP of the Americas. Ich kann mir nicht helfen, der Name klingt komisch.

Rackspace Cloud

Rackspace hat Zahlen veröffentlich. Demnach konnte man im ersten Quartal 2009 über 8000 neue Kunden von den eigenen Cloud Hosting Angeboten überzeugen. Damit bringt es die Rackspace Cloud auf 43.030 Kunden und einen Umsatz von 10.9 Millionen US-Dollar. Hierunter fallen allerdings nicht nur Hosting Kunden, sondern auch die Kunden des Cloud Files Speicherangebotes. Alle Details gibts hier.

Dies änder sich jetzt, denn Google hat Preise für zusätzlichen Verbrauch veröffentlich.

• $0.10 per CPU core hour. This covers the actual CPU time an application uses to process a given request, as well as the CPU used for any Datastore usage.
• $0.10 per GB bandwidth incoming, $0.12 per GB bandwidth outgoing. This covers traffic directly to/from users, traffic between the app and any external servers accessed using the URLFetch API, and data sent via the Email API.
• $0.15 per GB of data stored by the application per month.
• $0.0001 per email recipient for emails sent by the application