Ein Grundgerüst für gute Cloud-Apps

Mit dem 12 Factor App Manifest zur guten Cloud-App
Kommentare

Das 12 Factor App Manifest gibt einige Empfehlungen dafür, wie Web-Apps für die Cloud am Besten entwickelt werden können. Eine gute SaaS-Anwendung muss nämlich leicht skalierbar, schnell deploybar und gut portierbar sein. Das ist allerdings gar nicht so leicht zu gewährleisten. Die vom Manifest vorgeschlagenen Standards sind allerdings auch nicht auf alle Anwendungsfälle anwendbar.

Je häufiger deployt wird, desto besser – so sieht zumindest der Alltag vieler Entwickler aus. Das kann jedoch auch zu Problemen führen, wenn beispielsweise die Abhängigkeiten im Code nicht gut deklariert sind oder das Stoppen und erneute Starten einer App viel Zeit in Anspruch nimmt. Für alle diese Probleme schlägt das 12 Factor App Manifest Lösungen vor. Auch Anfänger in der Entwicklung cloudbasierter Anwendungen finden in diesem Konzept einen guten Leitfaden für ihre ersten Projekte, der dabei hilft, nichts Wichtiges zu vergessen.

Leitfaden für gute Apps

Natürlich ist aber eine solche Standardlösung nie für alle Anwendungsfälle geeignet. Während manche Teile des 12-Factor-App-Konzepts unstrittig sind, müssen andere Aspekte auf ihre Eignung für das konkrete Projekt geprüft werden. Immerhin stellt die Methodologie zwar einen guten Rahmen dar, ist aber auch kein Allheilmittel für jede App.

1. Die Codebasis

Dieser Punkt ist eigentlich selbstverständlich. Die Grundlage des 12-Factor-Konzepts lautet, dass der Code zentral auf GitHub oder einer anderen Source Control Plattform verwaltet wird, also allen beteiligten Entwicklern jederzeit in der gleichen Fassung zur Verfügung steht. So wird vermieden, dass es mehrere verschiedene Codeversionen gibt.

2. Abhängigkeiten

Implizite Dependencys sind immer eine schwierige Sache. Natürlich ist es notwendig, auf Datenbanken und Co zuzugreifen; wird die Anwendung in eine andere Umgebung übertragen, kann das aber problematisch werden. Ist eine Abhängigkeit nicht genau da zu finden, wo der Code sie sucht, läuft die Abfrage ins leere. Im Konzept der 12 Factor App ist darum vorgesehen, dass alle Abhängigkeiten explizit spezifiziert und kontrolliert werden. Dependencys werden als Libraries in den eigenen Code integriert und somit gemeinsam mit dem Code in andere Umgebungen portiert.

3. Configuration

Alle Daten, die sich auf die Konfiguration beziehen, sollten außerhalb des Codes abgelegt werden. Der Code ändert sich nicht durch den Wechsel in eine andere Umgebung; die Konfiguration hängt im 12-Factor-Modell aber durchaus von den Umgebungsvariablen ab. Darum ist hier eine Trennung sinnvoll – besonders auch in Bezug auf die Sicherheit. Passwörter gehören auch zu den Umgebungs- und Konfigurationsdaten und sollten niemals mit dem Code gemeinsam in die Source Control geladen werden. Dadurch entstehen nämlich große Sicherheitslücken, weil dann jeder beteiligte Entwickler Zugang zu allen Zugangsdaten hat.

4. Backing Services

Backing Services wie Datenbanken, Cache und Co sollten einfach austauschbar sein. Dependencys ändern sich nicht nur durch den Wechsel der Umgebung, sondern häufig auch im Laufe des Projekts. Wird der Cloud Storage Provider gewechselt, sollte diese Änderung nicht viel Arbeit am Projekt bedeuten. Darum sollten solche Services als angehängte Ressourcen behandelt werden, sodass für den Code schlussendlich kein Unterschied zwischen internen und externen Services besteht.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

5. Stages trennen

Änderungen am Code in der Runtime? Bloß nicht! Im 12-Factor-Konzept ist das tabu. Hier werden die Build-. Release- und Run-Zustände der Anwendung klar von einander unterschieden. Der Run-Zustand wird dadurch jederzeit stabil gehalten, kann ohne äußere Intervention laufen. So können sich die Entwickler ganz auf die vorherigen Stufen der Anwendung konzentrieren und in Ruhe testen und arbeiten, ohne dabei unter Umständen Probleme an der laufenden App zu verursachen.

6. Prozesse

Zustandslose Prozesse machen 12 Factor Apps stabiler. Dadurch ist die Anwendung insgesamt nicht davon abhängig, ob ein bestimmter Prozess ausfällt – ist das der Fall, läuft die App weiter und greif auf eine andere Ressource zu.  Das erhöht auch die Skalierbarkeit.

7. Port Binding

Die Anwendung muss vollständig per URL erreichbar sein. Für Web-Anwendungen gehört das natürlich eh zum Standard; im 12-Factor-Konzept gilt das allerdings für alle Services inklusive APIs, die unter Umständen auf diesem Weg schneller aufrufbar sind.

8. Concurrency

Sollten viele kleine Prozesse zusammengefasst werden oder jeder einzeln betrieben? In diesem Modell ist die Antwort klar: Alle Prozesse laufen einzeln und können somit einzeln gestartet, beendet oder skaliert werden. Das macht es möglich, beispielsweise neue Server problemlos zu integrieren und die CPU optimal auszunutzen.

9. Verfügbarkeit

Dadurch, dass Prozesse einzeln betrieben werden,  können sie schnell gestartet und gestoppt werden. Die App ist somit nach einem Update quasi sofort wieder verfügbar. Außerdem sollten 12 Factor Apps möglichst robust sein, wenn es um denn Neustart nach Abstürzen geht.

10. Development- und Produktions-Gleichheit

Die Entwicklungs- und Produktionsumgebung sollten so gleich wie möglich sein. Dadurch wird das berühmte „aber bei mir läuft es doch!“-Problem vermieden. Wenn die Umgebungen sich gleichen, können Testszenarios einfacher in die Realität übertragen werden, sodass weniger Fehler auftreten.

11. Logs

Logs geben Auskunft über Probleme mit dem Code. Das ist wichtig. Um sicherzustellen, dass diese Logs korrekt gespeichert werden, sollte darum ein gesonderter Service verwendet werden. Das ist nicht Aufgabe des laufenden Codes, der überwacht werden soll. Interne Fehler könnten nämlich in diesem Fall auch Logfiles beschädigen. Also sollten dazu externe Services genutzt werden.

12. Admin Prozesse

One-Off-Admin-Tasks sammeln wichtige Daten über das reale Verhalten einer Anwendung. Darum ist es wichtig, sie in der Produktions-Umgebung laufen zu lassen, nicht in der Entwicklungs-Umgebung oder mit einer veralteten Version des Codes. Ansonsten sind die ausgegebenen Daten nur schwer auf die real beobachteten Anwendungs-Probleme übertragbar.

Relevanz für das eigene Projekt prüfen

Das 12-Factor-Modell deckt also sehr viele Aspekte der Entwicklung einer Anwendung ab. Keiner der genannten Punkte ist dabei wirklich falsch, wenn es um Cloud-Dienste geht. Dennoch ist häufig eine Auswahl notwendig, um effektiv mit diesem Modell arbeiten zu können. Wer beispielsweise zur Fehlersuche nicht nur auf Logfiles vertraut, muss sich um diesen Punkt weniger Gedanken machen. Wenn der Code nicht mehrfach am Tag deployt wird, fällt die Startzeit der Anwendung nicht so sehr ins Gewicht. Auch die Skalierbarkeit ist natürlich immer dann besonders wichtig, wenn die Nutzerzahl schnell wächst und sehr groß ist. Insofern sind einzeln ablaufende Prozesse eher zu vernachlässigen, wenn es um kleine Anwendungen geht.

Andererseits ist dieses Modell aber auch gut dazu geeignet, Anwendungen zukunftsorientiert zu gestalten. Zwar mag ein Projekt heute noch klein sein; wenn es in Zukunft wächst, sparen sich die beteiligten Entwickler durch einen Aufbau anhand dieser Faktoren viel Arbeit. Explizite Dependencys helfen außerdem dabei, Anwendungen in der Zukunft besser überarbeiten zu können und sollten somit auf jeden Fall bedacht werden. Und dass GitHub eine echt sinnvolle Erfindung ist, muss wohl keinem Entwickler erst gesagt werden.

Sprachunabhängig?

Die 12 Factor Apps Methodologie ist grundsätzlich in allen Programmiersprachen anwendbar. Keines ihrer Konzepte ist an eine spezifische Sprache gebunden; auch sind die Prinzipien Plattform-Unabhängig. So können beispielsweise auch Anwendungen, die in Containern laufen, problemlos nach dem 12-Factor-Modell gestaltet werden.

Bozhidar Bozhanov berichtet allerdings, dass aus der Perspektive eines Java-Entwicklers nicht alle Aspekte des 12-Factor-Modells gleichsam wichtig und gut anwendbar sind. So hält er es beispielsweise durchaus für vertretbar, bestimmte Dependencys einfach vorauszusetzen, statt sie mit dem Code zu verteilen. Müsste etwas erst nach dem Start des Codes durch die integrierte Dependency in einer Umgebung installiert werden, sprengt das für ihn den Rahmen des vertretbaren Aufwands. Wenn nämlich mehr als die Extraktion eines jar-Files notwendig ist, können schnell mehrere Tage Arbeit dafür anfallen eine Dependency in den Code zu integrieren. Hier sollte dann eher eine andere Lösung gesucht werden.

Auch hält er die Concurrency für nicht allzu relevant unter Java, das Unix-Prozesse versteckt ablaufen lässt. In Java lassen sich Logfiles außerdem einfach über loggack/slf4j managen, sodass externe Services dafür nicht notwendig sind.

12 Factors im IoT

Wenn es nicht mehr um Web-Apps geht, die in der Cloud betrieben werden, ändern sich außerdem einige wichtige Grundlagen. Im Internet of Things gelten teilweise ganz andere Regeln für Apps als im Web.

Statuslose Prozesse sind beispielsweise dann nicht mehr anwendbar, wenn es um den Onlinestatus der Geräte geht, die mit der App verbunden sind. Muss die App diesen Steuern, ist zumindest ein lokaler Status notwendig. Skalierbarkeit bedeutet in der IoT-Welt etwas anderes als in der Cloud, sodass die Concurrency in der IoT-Welt außen vor gelassen werden kann. Kommen weitere Geräte hinzu, bringen sie ihre eigene Hardware mit, nicht einfach nur neue Prozesse.

Problematisch wird es auch in Bezug auf die Ähnlichkeit der Entwicklungs- und Produktionsumgebung. Entwickelt werden IoT-Apps in einer virtuellen Umgebung, das Ziel ist hier aber die Verwendung der App in der realen Welt. Hier kann immer nur eine Annäherung erfolgen, sodass der Standard der 12 Factor Apps nicht erfüllt wird.

Hilfen zur Umsetzung des Konzepts

Am besten ist es natürlich, das Konzept der 12 Factor App ab Entwicklungbeginn einer Anwendung umzusetzen. Auch auf existierende Anwendungen können aber darauf angepasst werden. So gibt es beispielsweise einen Leitfaden dafür, wie WordPress-Seiten nach dem Manifest zu 12 Factor Apps gemacht werden können. Außerdem stellt der PaaS-Dienst Appfrog eine Plattform zur Verfügung, die Entwicklern einige Arbeit bei der Entwicklung von Anwendungen nach dem 12 Factor Konzept abnimmt.

Nicht für jeden – aber doch für viele

Auch wenn das Konzept der 12 Factor Apps also nicht für jeden Anwendungsfall geeignet ist, stellt es eine gute Basis dar, um einen Überblick über die Anforderungen des Deployments in der Cloud zu bekommen. Schlussendlich muss das Manifest allerdings nicht als enger Rahmen verstanden werden, sondern stellt eher ein Grundgerüst dar, um gute Apps zu entwickeln. Das ist natürlich mit viel Aufwand verbunden, sodass nicht jeder Entwickler dazu greifen möchte. Am Ende kann es aber durchaus sinnvoll sein, die eigene Arbeit zumindest mit dem Konzept abzugleichen und bewusst zu entscheiden, was wichtig ist und was nicht.

Aufmacherbild: Digital composite of hand presenting cloud and app icons with laptop via Shutterstock / Urheberrecht: wavebreakmedia

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -