Als einer der entscheidenden Faktoren für den Erfolg von Microsoft Windows wird immer wieder die Entwicklergemeinde genannt. Früh hat Microsoft erkannt, dass diese Entwickler Mehrwert schaffen und die Verbreitung von Windows fördern, wenn sie Applikationen für die Windows-Plattform entwickeln. Das Developers, Developers, Developers Video ist nahezu legendär.
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?
>>…Innovation im Web in offenen Plattformen zum betreiben der Webapplikation auf Serverseite. Es muss Entwicklern leicht gemacht werden diese Anwendungen zu entwickeln.
>>Wie seht ihr das ganze?
Im Java Umfeld wurden mit Spezifikationen wie JSR-168, 286 und 154 eine gute Basis dafür geliefert. Nun fehlen nur noch Cloud-Anbieter in diesem Umfeld, welche es mir ermöglichen meine Anwendungen nach diesen Spezifikationen einfach in den Container zu werfen.
Aber die werden kommen!