Platform as a Service mit deis.io

Entwickler wollen ihre Software möglichst einfach dort haben, wo sie den Anwendern Nutzen bringt. Mit dem Modell der 12-Factor Apps und Deis Workflow steht eine Plattform bereit, die vieles an Bereitstellung und Betrieb automatisiert.

Werkzeuge  –  0 Kommentare
Platform as a Service mit deis.io

Viele sind derzeit dabei, eine Cloud-Infrastruktur für ihre Applikationen zu schaffen, oder haben das bereits umgesetzt. Greifen sie zu IaaS-Angeboten (Infrastructure as a Service) wie Amazons EC2 oder VMwares vSphere, ist das allerdings nicht ohne eine Investition in neue Prozesse für Deployment und Management der Applikationen sowie eine entsprechende Architektur möglich. Eine Alternative sind hierbei Techniken, die schon eine solche Struktur anbieten und somit bei der Gestaltung der Prozesse helfen.

PaaS-Angebote (Platform as a Service) sind hierfür eine gute Basis, da sie von der technischen Infrastruktur abstrahieren. Dabei bieten sie Benutzern eine Sicht auf eine Ebene der Applikation, die einzelne Komponenten wie Server, Netzwerk und Lastverteilung selbstständig verwaltet. Um Anwendungen auf einer solchen Plattform einfach skalieren zu können, sind sie allerdings anzupassen beziehungsweise von vornherein entsprechend aufzubauen.

Eine Architektur, um Webapplikationen auf diese Weise zu betreiben, stellen die sogenannten 12-Factor Apps dar. Die Theorie dahinter ist aus den Erfahrungen des PaaS-Betreibers Heroku entstanden. Er unterstützt seit Beginn Applikationen auf Basis von Ruby und Rails. Nach der Übernahme durch Salesforce sind weitere Plattformen wie PHP, Node.js und Java dazu gekommen. Die dabei gewonnenen Erkenntnisse hat Adam Wiggins gesammelt und veröffentlicht.

Viele der Eigenschaften einer solchen 12-Factor-Applikation sollte man mittlerweile als selbstverständlich betrachten. Dass der Code einer Revisionskontrolle unterliegt, wird deswegen ebenso als Standard betrachtet wie die Tatsache, dass man Test- und Produktionsumgebungen möglichst ähnlich halten sollte. Auch das Verwalten von Abhängigkeiten, zum Beispiel mit Maven im Java-Bereich, kommt vielerorts in traditionellen Set-ups zum Einsatz. Daher geht der Autor im Folgenden nur auf Punkte ein, die von einer "klassischen" Enterprise-Umgebung mit Applikationsservern, wie bei der Java Enterprise Edition (Java EE), abweichen.

Im Umfeld von Java EE hat sich für die Konfiguration von Anwendungen mittlerweile eine große Vielfalt etabliert. Neben Property-Dateien werden hier oft die Konfiguration per JNDI (Java Naming and Directory Interface) bereitgestellt oder eine selbstgebaute Lösung gewählt. 12-Factor Apps versuchen, das zu standardisieren, indem das Bereitstellen von Konfigurationsdaten über Umgebungsvariablen erfolgt. Das ist relativ einfach umzusetzen, die meisten Programmiersprachen unterstützen das.

Als sogenannte Backing Services bezeichnet man Dienste, die die Applikation über das Netzwerk anspricht. Das können zum Beispiel Datenbanken, Speicherdienste oder Messaging-Systeme sein. Die Anbindung an einen solchen Service erfolgt durch die Konfiguration einer URL oder eines ähnlichen Identifikators. Dabei geht die Applikation von der Annahme aus, dass sich die Schnittstelle zum Dienst nicht ändert und nur der Ort angegeben wird.

Ein weiterer deutlicher Unterschied zu klassischen Applikationsservern ist das Prozessmodell. Die Anwendung ist in mehrere Typen von Betriebssystemprozessen unterteilt. Dabei ist pro Prozess auch nur eine Art von Interaktion erlaubt. Bei einem Webserver darf daher innerhalb des Prozesses nur die Auslieferung von Webseiten erfolgen. Sollen im Hintergrund noch weitere Aktionen erfolgen, sind sie in einem eigenen Prozess zu erledigen. Diese sogenannten Admin-Prozesse haben nur eine begrenzte Laufzeit. Nach der Ausführung beenden sich alle Programme, zum Beispiel die Aggregation von Daten oder das Einspielen von Änderungen in eine Datenbank.

Die Kommunikation mit der Applikation erfolgt dabei über einen Netzwerk-Port. Ein anderer Zugriff von außen, etwa auf die Festplatte der Laufzeitumgebung, ist nicht erlaubt. Der Port wird von der Laufzeitumgebung bereitgestellt und dann von außerhalb des Laufzeitsystems zugänglich gemacht. Durch den definierten Zugang kann man die Applikation wieder als Backing Service für eine andere Anwendung bereitstellen; hierfür ist lediglich ihre Adresse bekannt zu geben.

Ein weiterer Effekt der relativ einfachen Struktur der Prozesse ist die hohe Skalierbarkeit. Da die Zuständigkeiten zwischen den verschiedenen Arten von Prozessen vollständig getrennt sind, lässt sich bei Bedarf jederzeit eine weitere Instanz eines Prozesses erstellen, um bei Engpässen die Kapazität zu erhöhen. Hierzu ist es allerdings nötig, dass die Prozesse zustandslos aufgesetzt sind. Daher sind alle Daten, die über den aktuellen Request hinaus erhalten bleiben sollen, in einem Backing Service wie einer Datenbank abzulegen. Zusätzlich ist die Nutzung des Dateisystems und Hauptspeichers als Cache nicht erlaubt. Sogenannte "Sticky Sessions" verbieten sich daher, da das Laufzeitsystem ebenfalls keine Garantie abgibt, dass der Prozess, der den letzten Request bearbeitet hat, den nächsten auch erhält. Daten, die nicht persistent sein sollen, sind daher in einem Caching-System wie Redis abzulegen. Für eine weitergehende Skalierbarkeit muss man darauf achten, dass sich die Prozesse schnell starten und wieder beenden lassen.

Ebenfalls abweichend von der traditionellen Applikationslandschaft ist die Behandlung von Log-Daten. Normalerweise werden sie als Dateien auf die Festplatte geschrieben und stehen dann zur Durchsicht bereit. In einer 12-Factor App ist das schwierig, da die Umgebung eines Prozesses inklusive Dateisystem nach dessen Ende entfernt wird. Log-Nachrichten betrachtet man daher als Abfolge von Events. Die Applikation gibt die Nachrichten direkt auf der Standardausgabe aus. Von dort sammelt sie das Laufzeitsystem ein und stellt es dem Verwalter der Applikation bereit. Möglich ist auch eine gesammelte Weitergabe der Log-Nachrichten an ein anderes System zur Ausgabe und Analyse.