Proprietäre PaaS

Nachdem ich zuletzt die Open Source PaaS (Platform as a Service) Technologien Cloud Foundry und OpenShift vorgestellt habe, wende ich mich in diesem Blogpost zwei proprietären PaaS zu.

Wie zuvor liegt der Fokus auf dem Deployment einer Beispielapplikation, welche an diverse Datenservices angebunden werden muss. Die Kriterien, nach welchen dieses Deployment sowie weitere EIgenschaften der PaaS beurteilt werden, wurden ebenfalls in einem vorherigen Blogpost beschrieben.

Architektur der Testapplikation
Architektur der Testapplikation

Google App Engine

Die App Engine ist der PaaS Teil der Google Cloud Platform und basiert wie OpenShift auf Kubernetes. Die Entwickler müssen dem Deployment Artefakt eine Konfigurationsdatei mitgeben, welche beispielsweise die Laufzeitumgebung bestimmt, in welcher das Artefakt deployed wird. Dies entspricht in etwa der “Source-to-image” Deployment Methode von OpenShift, die Plattform baut also basierend auf dem Quellcode das Image für die Laufzeitcontainer selber. Dieses Image wird dann Kubernetes übergeben, so dass die Orchestrierung der Container analog wie bei OpenShift funktioniert.

Google App Engine
Die Google App Engine basiert auf Kubernetes, welches auf der virtuellen Google Infrastruktur (Compute Engine) läuft. Apps können in Projekte unterteilt werden.

Neben den Engines bietet die Cloud Plattform auch Datenservices wie Datenbanken, welche in derselben Projektabstraktion verwendet werden können. Die Authentisierung zwischen den Applikationen und diesen Service Instanzen funktioniert über den Google SSO Dienst, so dass die Verbindungsdaten oft nur aus einer URI bestehen. Neben mySQL Datenbanken bietet die Plattform vor allem Google-spezifische Services wie Memcache (Caching und Memory Sharing), Blobstore, Datastore (NoSQL) oder Pub/Sub (Messaging). Diese sind teilweise verfügbar, ohne dass sie extra aktiviert werden müssten.

Das Deployment der Test App benötigt folgende Schritte:

  1. Erstellen einer mySQL Instanz.
  2. Aktivieren der mySQL API.
  3. Anlegen einer neuen mySQL Datenbank.
  4. Erstellen und abonnieren eines neuen Themas beim Pub/Sub Dienst.
  5. Anpassen des Quellcodes für Pub/Sub wie auch für den NoSQL Datastore.
  6. Login mittels Google SSO, d.h. es reicht im Browser seine Identität zu bestätigen.
  7. Anlegen und konfigurieren der Laufzeitumgebung in einer App Engine Konfiguration.
  8. Deployen der Applikation anhand dieser Konfiguration.
Google Cloud Konsole
Das Dashboard der Google Cloud Platform lässt sich frei konfigurieren und integriert neben der App Engine auch alle anderen Google Dienste für Entwickler.

Die meisten Schritte habe ich jeweils direkt im UI erledigt, da ich mich mit dem CLI Tool “gcloud” nicht gut auskenne. Im Schritt 5 hat sich zudem der Nachteil von proprietären Datenservices gezeigt: Der Quellcode muss extra für den jeweiligen Service geschrieben werden, Abstraktionen wie die von Spring angebotenen funktionieren nicht oder nur begrenzt. In diesem Fall wäre es also besser gewesen, die Applikation von Anfang an für die proprietären Google Services zu bauen. Positiv muss dagegen erwähnt werden, dass die Datenservices über die angebotene Java API sehr einfach zu verwenden sind.

Heroku

Heroku ist einer der ersten PaaS und diente als Vorbild für Cloud Foundry, weshalb die Architektur der beiden Technologien ähnlich ist. Unterschiedlich ist der Startpunkt eines Deployments, da Heroku immer den Source Code und eine Beschreibung der Abhängigkeiten in einem internen Git Repository erwartet. Die Plattform baut aus diesem Code dann das Container Image, welches deployed und skaliert wird. Wie das Container Image und die beinhaltete Laufzeitumgebung zusammengesetzt werden, geschieht analog wie bei Cloud Foundry, es können sogar dieselben Buildpacks eingesetzt werden. Ebenso bietet Heroku einen “Add-ons Marktplatz” an, in dem einer Applikation Add-ons, was Instanzen von Datenservices entspricht, zur Verfügung gestellt werden können. Der Marktplatz enthält viele externe Angebote, meist bekannte Open Source Technologien wie zum Beispiel PostgreSQL oder Redis.

Die Kollaboration an einer oder mehreren Applikationen kann in Teams organisiert werden. Jeder Benutzer hat zudem seinen eigenen persönlichen Bereich. Das Deployment der Testapplikation in meinem Bereich benötigt folgende Kommandos:

  1. Login mit Benutzername und Passwort.
  2. Eine App wird erstellt.
  3. Das lokale Git Repository wird direkt in das Heroku Git Repository repliziert. Heroku führt den Maven Build aus und erstellt mit dem resultierenden JAR eine Laufzeitumgebung in einem Container.
  4. Wir erstellen je ein Add-on ClearDB, MongoLab und CloudAMQP.

Da die Serviceinstanzen automatisch an die aktuelle App gebunden werden und diese neugestartet wird, geht das Deployment sogar noch schneller als mit Cloud Foundry! Die wenigen nötigen CLI Kommandos finden Sie in meinem Git Repository.

Heroku
Die Testapplikation mit den drei Add-ons.

PaaS vergleichen

Dieser Blogpost hat kurz beschrieben, wie eine einfache Testapplikation in der App Engine und Heroku ausgerollt werden kann. Dies dient als Vorlage für den Vergleich dieser Technologien mit den zuvor vorgestellten Cloud Foundry und OpenShift PaaS. Im nächsten und letzten Beitrag werde ich diesen Vergleich auf Basis der ebenfalls früher vorgestellten Kriterien vornehmen und zeigen, welche Technologie in welchen Anwendungsfällen am meisten Sinn macht. Bei der Einführung einer PaaS sollten Sie jedoch auch immer selber eine präzise Evaluation durchführen, die ihre spezifischen Bedürfnisse berücksichtigt.

Haben Sie Fragen zu diesem Thema oder brauchen Sie Unterstützung bei der Einführung von PaaS, können Sie sich gerne bei mir melden.

Kommentar verfassen