Java-Anwendungen in der Google App Engine mit CloudSQL

Die Google App Engine

Die Google App Engine ist Googles Platform as a Service-Produkt, ermöglicht also das Deployen von Anwendungen in der Google-Cloud-Infrastruktur ohne die Notwendigkeit, sich selbst um sonst benötigte Infrastruktur wie VMs, Netzwerk oder Speicher kümmern zu müssen. Googles App Engine ist damit als Alternative zu Heroku zu betrachten, einem der ältesten und bekannten PaaS-Dienstleister.

Im Vergleich zu anderen Google Compute-Produkten wie beispielsweise Googles Kubernetes Engine ist es nicht nötig, sich um die zugrundeliegende Infrastruktur zu kümmern. Ist es bei der Kubernetes Engine beispielsweise erforderlich, die Anzahl der permanenten VMs, deren Ausstattung mit Arbeitsspeicher und CPUs und die konkrete Art der Provisionierung von Speicher-Ressourcen zu verwalten und der tatsächlichen Verwendung anzupassen, übernimmt Googles App Engine dies selbstständig. Zwar kann man auch einen Kubernetes-Cluster in Googles Compute Engine dynamisch und automatisch skalieren, allerdings erfordert das einen nicht zu verachtenden Umfang an Konfiguration und ist keineswegs "out of the Box" verwendbar. Ausführliche Lasttests und Tuning sind hierbei unumgänglich.

Im Gegensatz dazu erlaubt Googles App Engine es, sich vollständig auf die Entwicklung der Anwendung zu fokussieren. Hierin deployte Anwendungen skalieren sofort und automatisch unter Last auf mehrere Instanzen und in Ruhezeiten auch wieder zurück. Alle systemseitigen Anforderungen - sei es die Bereitstellung von IPv4- und IPv6-Adressen und SSL-Zertifikaten oder das Routing von Domain-Namen - werden von Google übernommen. Mit Googles StackDriver erhalten Entwickler ohne weitere Konfiguration ein sehr mächtiges Werkzeug zur Fehlerdiagnose und statistischen Auswertung.

Gerade für Startups und kleine Anwendungen ist die App Engine auch noch aus einem anderen Grund interessant: Solange die Anwendung nur geringe Last erzeugt, fallen keinerlei Kosten an. So kann eine Anwendung bereits produktiv genutzt werden, ohne dass dafür laufende Kosten entstehen. (Hier gibt es weitere Informationen zu den App Engine-Preisen.)

Standard Environment vs. Flexible Environment

//SEIBERT/MEDIA hat Kompetenzen in vielen Programmiersprachen, um je nach Situation das bestmögliche Werkzeug bereitstellen zu können. Mit Abstand am weitesten verbreitet ist jedoch Java, sodass sich die folgende Betrachtung auf Java fokussiert.

Eine der Stärken der App Engine besteht jedoch darin, dass sie eine Vielzahl von Sprachen unterstützt – mit Node.js, Java, Ruby, C#, Go, Python und PHP fast alles, was in der modernen Webentwicklung eingesetzt wird.

Für Java bietet Googles App Engine zwei Ausführungsumgebungen an: Standard und Flexible. Beide stellen schlussendlich dieselbe Dienstleistung bereit, verwenden aber grundsätzlich unterschiedliche Technologien und bieten dadurch sehr unterschiedliche Vorteile und Beschränkungen.

Standard Environment

Im Standard Environment wird die Java-Anwendung in einer Java-Sandbox ausgeführt. Konkret verhält sich diese wie ein Jetty Application-Server, in dem die Anwendung ausgeführt wird.

Der größte Vorteil hierbei ist, dass Googles App Engine mehr Freiheiten bei der Skalierung der Anwendung hat. Unter Last kann die Anwendung innerhalb von Sekunden auf zusätzlichen Application-Servern deployt werden und sofort Anfragen verarbeiten. In Zeiten ohne Anfragen wird die Anwendung aus allen Application-Servern entfernt. Daher ist das Deployment im Standard-Environment auch zunächst kostenfrei. Konkret fallen keine Gebühren für den ersten Application-Server an ("always free"); erst wenn ein zweiter nötig wird, um alle eingehenden Anfragen zu bearbeiten, werden dieser und alle folgenden berechnet.

Der größte Nachteil dieser Deployment-Art ist, dass die Sandbox der Anwendung teilweise beachtliche, wenn auch erwartete Restriktionen auferlegt. So können keine direkten TCP/UDP-Verbindungen hergestellt und folglich keine externen Datenbanken oder Support-Dienste wie Message Queues o.ä. angebunden werden.

Dateizugriffe sind nur mittels eines Wrappers möglich, der die Dateisystem-Operationen auf einem Google-Bucket ausführt. Dies begrenzt die Möglichkeit, mit temporären Dateien zu arbeiten. Auch externe Tools wie ImageMagic oder ffmpeg stehen nicht zur Verfügung; wir müssen alle Aufgaben nativ in Java implementieren. Zudem sind echte Background-Prozesse im Standard-Environment nicht möglich, vergleichbares lässt sich aber mittels Googles Task Queue oder PubSub-Diensten abbilden.

HTTP-Requests dürfen nicht länger als 60 Sekunden dauern, bevor sie durch die App Engine beendet werden. Längere Prozesse müssen wir über die Task Queue oder andere Google-Dienste in den Hintergrund verlagern.

Zusammenfassend kann man sagen, dass Anwendungen, die im Standard Environment laufen, deutlich enger in die Google-Infrastruktur integriert werden müssen, dafür aber auch von einem angenehmen Preis- und Skalierungsmodell profitieren können.

Flexible Environment

Das Flexible Environment basiert auf Docker-Containern: Entwickler packen die Anwendung in einen Container ein. Dabei können auch binäre Tools wie ImageMagick oder ffmpeg oder binäre Bibliotheken mit eingepackt und von der Anwendung verwendet werden.

Der größte Nachteil hierbei ist, dass das Starten einer neuen Container-Instanz bis zu einigen Minuten dauern kann. Daher fährt Googles App Engine die Anwendung nie auf Null herunter: Es gibt immer einen Container, der aktiv ist.

Da immer mindestens eine Instanz laufen muss, entfallen die Restriktionen zu Hintergrundprozessen. Einzelne Anfragen dürfen bis zu 60 Minuten dauern und auch Netzwerkverbindungen und temporäre Dateien innerhalb des Containers sind möglich.

Mit Docker als gemeinsamem Nenner können wir Anwendungen, die für das Flexible Environment entwickelt wurden, später in allen Hosting-Lösungen verwenden, die Docker-Container unterstützen. Umgekehrt können wir auch Anwendungen, die nicht konkret für Googles Laufzeitumgebung entwickelt wurden, in das Flexible Environment migrieren und so von der automatischen Skalierung profitieren.

Für das Flexible Environment gibt es keine Always free-Option, hier fallen ab der ersten Instanz Kosten an. (Hier sind Details zu den Restriktionen der Environments.)

CloudSQL

Egal ob im Standard oder Flexible Environment - die meisten Anwendungen benötigen einen Dritt-Service zum Speichern von Daten. Während sich für unstrukturierte Daten der Google Cloud Storage anbietet und für semistrukturierte Daten die NoSQL-Datenbank Google Datastore geeignet erscheint, werden die meisten Anwendungen vor allem strukturierte Daten in einer relationalen Datenbank speichern wollen.

Hierfür bietet sich Googles CloudSQL als komplett verwaltete Datenbanklösung an. CloudSQL gibt es in den beiden im Open-Source-Bereich üblichen Geschmacksrichtungen MySQL und PostgreSQL, wodurch wir auch bestehende Anwendungen ohne größeren Aufwand in die Google App Engine mit CloudSQL migrieren können.

Im Gegensatz zu selbstbetriebenen SQL-Datenbanken ermöglicht es Googles CloudSQL, sonst sehr aufwändige oder komplexe Aufgaben wie das Konfigurieren von Read-only- oder Failover-Replikaten (bei Bedarf auch über verschiedene Datencenter hinweg) mit wenigen Klicks zu erledigen.  CloudSQL-Datenbanken werden in vom Nutzer konfigurierten Wartungsfenstern automatisch aktualisiert und gesichert. Sicherungsdateien werden automatisch in mehreren Rechenzentren gespeichert und Restore-Operationen lassen sich mit wenigen Klicks ausführen.

Google App Engine

Beide Datenbanksysteme können auf Wunsch von externen IP-Adressen zugänglich gemacht werden, sodass wir die gewohnten Datenbank-Tools weiter benutzen können. Für die Verbindung von Java-Anwendungen zu CloudSQL-Datenbanken wird die Verwendung einer speziellen Connector Factory empfohlen, die Autorisierung und Verschlüsselung transparent regelt.

Für die Entwicklung in Java ist es problemlos möglich, JPA, SpringData oder ein anderes ORM-Framework mit CloudSQL einzusetzen. (Weitere Informationen zu Java-Anwendungen in Googles App Engine und CloudSQL sind hier zu finden.)

Java-Entwicklung für die Google AppEngine

Googles App Engine SDK stellt eine lokale Entwicklungsumgebung als Maven-Plugin zur Verfügung, sodass wir App Engine-Anwendungen lokal entwickeln und testen können. Die dazu verwendeten Tools sind im Java-Umfeld wohlbekannt und machen den Einstieg sehr einfach.

Dabei werden einige Hilfssysteme wie die Task Queue ebenfalls auf dem lokalen Computer ausgeführt. Leider gilt dies aber nicht für alle Dienste, beispielsweise müssen wir selbst Vorkehrungen treffen, um lokal eine andere Datenbank (beispielsweise eine lokale PostgreSQL-Instanz) zu verwenden.

Auch die Einbindung von üblichen Entwicklungsumgebungen wie Spring Boot ist – zumindest für das Standard Environment – nicht so einfach wie man dies erwarten könnte. Ernstzunehmende Hürden gibt es hier allerdings wiederum auch nicht zu überwinden.

Schlussfolgerung

Für Startups und andere Projekte, bei denen gerade zu Beginn äußerst genau auf das Budget geachtet werden muss, kann es sich anbieten, die eigene Anwendung für das Standard Environment zu entwickeln. Im Erfolgsfall erfolgt die Skalierung automatisch und ohne Eingreifen. Tools wie Googles StackDriver können die Entwickler massiv in ihrer Arbeit unterstützen.

Google App Engine    Google App Engine

Ist die Anwendung bereits recht weit fortgeschritten oder ist bereits klar, dass die sie einen regelmäßigen Nutzerkreis haben und dass permanent eine Instanz laufen wird, lohnt sich ein Umbau auf die Restriktionen des Standard Environment nicht. Dann ist es vermutlich effizienter, die Anwendung zu "containerisieren" und über das Flexible Environment auszuführen. Dies ermöglicht später auch eine Migration zu einer anderen Container-Hosting-Umgebung, beispielsweise einem Kubernetes-Cluster.

Der Schritt hin zu einem eigenen Kubernetes-Cluster sollte hingegen wohlüberlegt sein. Die Konfiguration und der Betrieb eines stabilen Clusters erfordern unserer Erfahrung nach eine genaue Planung der Anforderungen und regelmäßige Betreuung und Wartung.

Gerne beraten wir Sie zu allen Themen rund um App Engine, CloudSQL, Kubernetes und anderen Google-Cloud-Services: Melden Sie sich bei uns!

Weiterführende Infos

Google Apps Script – Skript-Verwaltung mit dem App Scripts CLI (Clasp)
Apps für die Google G Suite und der Google App Maker
Hands-on-Confluence-Cloud-Apps mit Spring Boot und Atlassian Connect
G Suite: Funktionen, Möglichkeiten, Einführungsprojekte


Mehr über die Creative-Commons-Lizenz erfahren

ACHTUNG!
Unsere Blogartikel sind echte Zeitdokumente und werden nicht aktualisiert. Es ist daher möglich, dass die Inhalte veraltet sind und nicht mehr dem neuesten Stand entsprechen. Dafür übernehmen wir keinerlei Gewähr.

Schreibe einen Kommentar