Platform-as-a-Service (PaaS) gehört mit Abstand zu den Zukunftsthemen im Cloud Computing. Im Jahr 2011 kamen neben bereits bestehenden Anbietern wie Heroku, Cloud Foundry, Engine Yard, Beanstalk, Windows Azure, Force.com, OpenShift oder cloudControl, viele weitere hinzu, was die mediale Präsenz dieses Cloud Bereichs anhob. Nur um einen Service ist ein wenig ruhig geworden: Die Google App Engine.

Die Google App Engine war bereits sehr früh verfügbar

Die Google App Engine (GAE) gehört mit der Erscheinung im Jahr 2008 zu einer der ersten PaaS am Markt und war der einzige Service der Python und Java gleichzeitig unterstützte. Aber im Laufe der Jahre hat die Innovation rund um GAE deutlich nachgelassen.

Startups und Entwickler gehörten zu den Hauptnutzern von GAE. Das lag in erster Linie an den Möglichkeiten der weitestgehend kostenlosen Nutzung und den nicht notwendigen Investitionen in SDKs und Plugins. Ein weiterer Grund war die geringe Auswahl an Angeboten. Java und Python Entwickler würden niemals Windows Azure wählen, was zu diesem Zeitpunkt die einzige Alternative war. Nach und nach entwickelte sich Heroku (mittlerweile von Salesforce aufgekauft) zu einer echten Alternative für Python Entwickler, auf Kosten der Google App Engine. Doch bereits während der Anfangsphase der GAE hat Google es verpasst die riesige Anzahl an gehosteten Anwendung an Bord zu behalten und die wichtige Entwickler Community für sich zu gewinnen. Was ist also der Grund für den Abstieg der Google App Engine?

Refactoring und Vendor lock-in

Ein Hauptproblem der Google App Engine besteht in den massiven Änderungen die vorgenommen werden müssen, wenn eine Anwendung auf die GAE portiert werden soll. Befindet sich die Anwendung dann auf der GAE, kann sie ausschließlich die proprietäre API nutzen, was es Entwickler sehr schwierig macht, später die Plattform wieder zu wechseln. Selbst Standard Java Web Anwendungen müssen an vielen Stellen angepasst werden, um auf der GAE betrieben zu werden. Während Heroku weitere Funktionen hinzufügte und für eine bessere Kontrolle sorgte, schränkte Google die Entwickler mit der proprietären API ein.

Beta-Status und Innovationen

Microsoft, das für seine langen Release-Zyklen bekannt ist, hat es geschafft das Azure SDK mehrfach zu aktualisieren und das Management Portal häufig zu verbessern. Die Google App Engine orientiert sich an Googles „Beta-Status“ Tradition. So blieb die GAE für fast drei Jahre im Beta-Status, was professionellen Entwicklern nicht die Sicherheit gab, ihre Produktionsanwendungen auf die GAE zu portieren. Während Google in der jungen Vergangenheit mit Pull Queues, Cloud SQL und der Blobstore API viele der gewünschten Funktionen umsetzen konnte, hat es lange gedauert auf die Bedürfnisse der Kunden zu reagieren.

Schlechte Unterstützung für Unternehmensanwendungen

Lange unterstützte die GAE nur zustandslose Web Anwendungen. Technologisch betrachtet können auf der GAE somit nur Web Anwendungen entwickelt werden, die keine komplexe Business-Logik benötigen. Bspw. verfügt Windows Azure über ein Rollenkonzept (Web Roles), um Web Anwendungen zu betreiben und Worker Roles, um damit lang laufende Prozesse und komplexe Geschäftsregeln ausführen zu lassen. Ähnlich verhält es sich bei Heroku, wo der Web Dyno und Worker Dyno diese Funktionen aufteilen. Bis zur Einführung von Backends in der Version 1.5.0 (Mai 2011), machte diese mangelnde Unterstützung zur Aufteilung einer Anwendung es schwierig Unternehmensanwendungen auf die GAE zu migrieren.

Der Datenzugriff

Lange nutzte die Google App Engine ausschließlich Big Table als primären Datenspeicher. Amazon zog schnell mit SimpleDB nach, führte damit weitere Funktionen ein und veröffentlichte mit RDS einen Database-as-a-Service. Zuletzt folgt dann DynamoDB. Das Fehlen eines guten Speichers für Transaktionsdaten schränkte die Entwickler bei der Nutzung der GAE stark ein. Jede Anwendung die professionell eingesetzt werden soll, benötigt zwangsläufig eine Kombination aus relationaler und NoSQL-Datenbank, um innerhalb der Cloud zu skalieren. Die GAE verfügte nicht über diese Funktionen, die für Daten-intensive Anwendungen erforderlich sind. Services wie BlobStore und Cloud SQL kamen demnach viel zu spät.

Vermarktung

Mit der Google App Engine hatte Google die ideale Position, Startups eine kostengünstige Plattform anzubieten. Sie wäre ideal gewesen, um typische Web-Anwendungen für den Markt der Endverbraucher zu entwickeln und bereitzustellen. Allerdings hat Google sich hier von Anfang nicht deutlich positioniert. Typische Low-End Web-Anwendungen, die prädestiniert für den Einsatz auf der App Engine gewesen wären, haben sich für Heroku entschieden, wohingegen High-End Anwendungen und Anwendungen mit hohen Workloads zu Amazon EC2 gegangen sind. Die Einführung der Amazon Micro Instanzen und die Free Tier Angebote haben der Google App Engine zudem weiterhin geschadet. Bis heute kann man nicht eindeutig sagen, welchen Platz die Google App Engine auf der mittlerweile großen Landkarte des PaaS einnimmt. Soll sie, aus Sicht von Google, genutzt werden, um Low-End Web-Anwendungen zu betreiben oder doch lieber für Unternehmensanwendungen?

Kosten

Natürlich mag es niemand, wenn ein vormals kostenloser Service nun bezahlt werden muss. Jedoch muss Google mit der App Engine auch irgendwann Geld verdienen. Allerdings hielten die Entwickler das neue Preismodell für äußerst unangemessen. Es gab einen riesen Aufruhr in der Community, als Google die neue Preisstruktur vorstellte. So stellten viele Kunden fest, dass ihre Kosten plötzlich um das drei- bis fünffache steigen würden. Das führte zu einem großen Bruch mit der Community, wodurch u.a. einige Startups von der Google App Engine zu Amazon EC2 bzw. zu einem klassischen Web Hoster gewechselt sind.

Sonstiges

Die GAE Entwickler Community hat den Eindruck, dass die App Engine im Vergleich zu Android innerhalb von Google schlechter angesehen wird. Das führt ebenfalls zu einer schlechten Stimmung.

Google und VMware kündigten damals auf der Google I/O im Jahr 2010 eine Partnerschaft an, um Spring auf die Google App Engine zu portieren. Trotz der Ankündigung kaufte VMware dennoch RabbitMQ und WaveMaker und brachte mit Cloud Foundry seine eigene PaaS Lösung auf den Markt. Während VMware CloudFoundry als Open PaaS positionierte, blieb die Google App Engine auf der Strecke.

Ein weiterer Rückschlag für Google war der Verlust des bekannten GAE Evangelist Patrick Chanezon, der als Head of Developer Relations zu VMware wechselte, um damit CloudFoundry zu stärken.