In Zeiten von DevOps, also der immer engeren Zusammenarbeit zwischen Development- und Operations-Abteilungen, fällt auch immer wieder der Begriff PaaS. Unter PaaS (platform as a service) versteht man die Möglichkeit, operative Plattformen zum Betrieb von Webanwendungen auf einfache Art und Weise 'per service' aufzubauen. Kleineren Firmen wird somit ermöglicht, ohne eigene Operations-Abteilung eigenständig maßgeschneiderte Serverumgebungen aufzusetzen. Ich möchte in diesem Artikel den Aufbau eines PaaS an einem konkreten Beispiel darstellen, um zu zeigen, wie einfach der Betrieb einer Webanwendung mit Hilfe eines PaaS ist.

Red Hat bietet mit OpenShift (https://www.openshift.com/) eine PaaS an, die in ihrer kleinsten Variante sogar vollkommen kostenlos ist. Ich werde anhand von OpenShift die Funktionsweise einer PaaS exemplarisch erklären.

Um sich bei OpenShift zu registrieren, benötigt man nur einen Email-Account. Nachdem der Account eingerichtet ist, hat man die Möglichkeit, sogenannte Applikationen anzulegen:

Dieser Schritt ist der erste und gleichzeitig der wichtigste (siehe Bild 1). Hier werden die Applikationen erstellt und mit Leben gefüllt. Zu einer Applikation können mehrere Cartridges hinzugefügt werden, die die konkreten Bauteile der Serverumgebung repräsentieren. Wenn man z.B. ein Spring MVC Projekt veröffentlichen möchte, legt man als erstes einen Tomcat 7 Server an.

Abb. 1: Auswahl der Applikationen

Bevor die Applikation angelegt wird, muss man noch einige grundlegen

de Einstellungen vornehmen (siehe Bild 2). Am wichtigsten wird wohl die URL sein, unter der die Applikation später erreichbar sein wird. Üblicherweise besteht die URL aus einem Cartridge-Bezeichner sowie einem Namespace, so dass schließlich folgende Form vorliegt:
http://<cartridge-name>-<namespace>.rhcloud.com

Es ist auch möglich, von einer eigenen Adresse auf OpenShift zu verweisen. Die Erläuterungen dazu würden allerdings hier den Rahmen sprengen.

Des Weiteren kann man ein git Repository angeben, welches die Sourcen enthält und direkt eingebunden wird. Sofern die Applikation dynamisch skalierbar sein soll, kann man dies hier angeben. Ein Loadbalancer sorgt dann dafür, dass - sofern notwendig - weitere Server zugeschaltet (und auch wieder abgeschaltet) werden.

Abb. 2: Einstellungen für die Tomcat 7 Cartdige
 

Zusätzlich zum Server benötigt man in den meisten Fällen natürlich noch eine Persistenzschicht. Hier kann man wieder aus mehreren Möglichkeiten wählen. Ich entscheide mich für eine MongoDB Instanz und lasse direkt noch zum besseren Monitoring der DB das Tool RockMongo installieren. Man erhält eine Bestätigung mitsamt den Credentials, die man auf Codeseite (sowie auf Adminseite) zum Zugriff auf die DB benötigt.

Im Grunde hat man nun eine lauffähige Umgebung. Allerdings beinhaltet diese momentan ggf. noch keine eigenen Sourcen. Um diese anzulegen, benutzt man git: gibt man beim Erstellen der Applikation ein bestehenden Repository mit an, so werden die Sourcen direkt importiert. Gibt man kein Repository an, so wird ein dummy-Projekt angelegt. So oder so macht man schließlich ein 'git clone', dieses Projektes . Dafür muss man einen SSH-key hochladen (siehe Bild 3 rechts oben). Ist dies geschehen, macht man ein 'git clone', um alle weiteren Änderungen dann auf diesem Projekt auszuführen und zu pushen.

Ein git push von lokalen Commits führt dazu, dass OpenShift das entsprechende Projekt aktualisiert und abschließend neu deployt!

Bei der JAX im letzten Jahr (2013) wurden verschiedene PaaS-Anbieter nochmals vorgestellt (http://jaxenter.de/artikel/Java-PaaS-Parade-Das-grosse-Schaulaufen-Cloud-Anbieter). Die Ergebnisse sind in Tabelle 1 zusammengefasst. Im Grunde sind alle Angebote ähnlich, da es meistens ein kostenloses (zum Testen) Lizenzmodell gibt, welches dynamisch - abhängig vom Speicherbedarf und Traffic - im Preis steigt. Auch Skalierbarkeit ist bei allen Angeboten gegeben, wobei dies nicht immer automatisch geschieht. Der bekannteste als auch potenteste Anbieter wird wohl Amazon sein. Hier ist man sicherlich bei Verfügbarkeit und Skalierbarkeit auf der sicheren Seite. Heroku und OpenShift haben jedoch den Charme, dass es einfach Spaß macht, Serverumgebungen per Baukasten-Prinzip zusammenzustecken. Heroku bietet zudem eine Unmenge an (teilweise überflüssigen?) Add-Ons, die dem Entwickler Anreize für weitere Applikationen geben (Messaging, Suche, Mail-/SMS-Versand, etc.).

Vergleich mit anderen PaaS-Angeboten:

Fazit

Die Veröffentlichung von Webanwendungen basierend auf state-of-the-art Technologien erfordert nicht immer Geld, Zeit und tiefgreifende Kenntnisse über Serverstrukturen. PaaS Anbieter liefern den Aufbau von Serverlandschaften per drag&drop und gewährleisten sogar Skalierbarkeit out of the box. Ich habe hier am Beispiel von OpenShift von Red Hat demonstriert, wie einfach es ist, eine Serverlandschaft für eine Webanwendung inklusive Persistenzschicht "zusammen zu klicken". Das Lizenzmodell von OpenShift ermöglicht sogar den kostenlosen Betrieb von kleinen Anwendungen, so dass man das Angebot gut zum Testen von neuen Serverkomponenten benutzen kann.

Links & Literatur

[1] https://www.openshift.com

[2] http://jaxenter.de/artikel/Java-PaaS-Parade-Das-grosse-Schaulaufen-Cloud-Anbieter

[3] http://aws.amazon.com/de/elasticbeanstalk/

[4] https://www.heroku.com/

[5] http://www.cloudfoundry.com/

[6] https://developers.google.com/appengine/

[7] www.sap.com/pc/tech/cloud/software/cloud-platform/index.html‎

erschienen im JavaMagazin 12.14