Automatisierte Konfiguration, optimale Komptabilität mit dem Betriebssystem, bedarfsgerechte Cloudnutzung und flexible Skalierbarkeit sind wichtige Kriterien bei der Web-App Entwicklung.
Die Twelve-Factor App Methode berücksichtig diese Faktoren, um die Entwicklung objektiv und effizient umzusetzen. Doch was genau ist die „The Twelve-Factor App” Methode? Dies haben wir im Libelle IT Glossar erklärt.
In unserer Blogreihe zur Twelve-Factor App Methode: „Die Twelve-Factor App Teil 1: Codebase, Dependencies, Config Backing Services“ und „Die Twelve-Factor App Teil 2: Erstellen, Freigeben, Ausführen, Prozesse, Anschlussbindung, Gleichzeitigkeit“ haben wir die ersten acht Faktoren genauer beleuchtet.
Im dritten Teil beleuchten wir nun die nächsten vier Faktoren. Zusammengefasst lauten ihre Grundsätze wie folgt:
IX. Einweggebrauch: Robuster mit schnellem Start und problemlosen Stopp
X. Dev-Prod-Vergleichbarkeit: Entwicklung, Staging und Produktion so ähnlich wie möglich halten
XI. Logs: Logs als Strom von Ereignissen behandeln
XII. Admin-Prozesse: Admin/Management-Aufgaben als einmalige Vorgänge behandeln
Cloud-native Anwendungsprozesse sind Wegwerfprozesse, das heißt, sie können jederzeit gestartet und beendet werden. Dabei versuchen Prozesse, die Startzeit zu reduzieren, was zu einer größeren Agilität bei der Freigabe und Skalierung von Prozessen führt. So auch bei den Prozessen einer Zwölf-Faktor App. Sehr lange Startzeiten können in der Cloud möglicherweise verhindern, dass die Anwendung überhaupt gestartet wird.
Andererseits kann es schwierig sein, eine Anwendung nach einem Ausfall wieder zu starten, wenn sie nicht ordnungsgemäß und rechtzeitig heruntergefahren wird. Langlaufende Operationen müssen unabhängig ausgeführt oder als Backing-Service ausgelagert werden, um die Cloud-native Architektur zu nutzen. Ziel ist es einen, Robuster schnellen Start und problemlosen Stopp zu gewährleisten. (Quelle)
Bei diesem Faktor geht es darum, dass die Entwicklungs-, Staging- und Produktionssegmente der Anwendung, oder besser gesagt, alle Umgebungen so ähnlich wie möglich sind. Indem der Abstand zwischen Entwicklung und Produktion so gering wie möglich gehalten wird, ist die 12-Faktoren-Anwendung für eine kontinuierliche Anwendungsbereitstellung gedacht. Es gibt dabei drei Schlüsselaspekte zu berücksichtigen: Zeitlücke, Personallücke und Werkzeuglücke.
Das oberste Ziel ist es, Entwicklungen, Staging und Produktion so ähnlich wie möglich zu halten.
Um das Verhalten einer laufenden App sichtbar zu machen, werden Logs genutzten. Üblicherweise werden sie in Server-basierten Umgebungen in eine Datei auf die Platte geschrieben, dabei handelt es sich aber lediglich um ein Ausgabeformat (Logdatei).
Logs sind der Stream von aggregierten, nach Zeit sortierten Ereignissen und zusammengefasst aus den Output Streams aller laufenden Prozesse und unterstützenden Dienste. Normalerweise werden Protokolle im Textformat gespeichert, wobei jede Zeile ein einzelnes Ereignis wieder gibt. Bei den Protokollen handelt es sich um eine zeitlich geordnete Folge von Ereignissen, die von einer Anwendung erzeugt werden. Sie sollten dabei wie Ereignisströme behandelt werden. Der Ereignisstrom kann an ein System zur Indizierung und Analyse von Protokollen weitergeleitet, in einer Datei gespeichert oder in Echtzeit über die Ausgabe eines Terminals angezeigt werden.
Cloud-native Anwendungen schreiben alle ihre Protokolle nach stdout und stderr, da sie in der Regel sehr wenig über das Dateisystem wissen, auf dem sie laufen. Die gesamte Codebasis einer Anwendung wird einfacher, wenn sie vom Wissen über die Protokollspeicherung getrennt ist. Wenn Änderungen an den Protokollen erforderlich sind, muss die Anwendung selbst nicht geändert werden.
Eine 12-Faktoren-Anwendung sollte niemals versuchen, in Protokolldateien zu schreiben oder diese zu pflegen, und sie sollte sich nicht um die Weiterleitung oder Speicherung ihres Ausgabestroms kümmern. Das bedeutet sie kümmern sich nie um das Routing oder die Speicherung ihres Output Streams. (Quelle)
Der letzte Faktor weist darauf hin, dass alle Verwaltungs- und Managementoperationen als einmalige Prozesse in derselben Umgebung wie die typischen langlaufenden Prozesse der Anwendung ausgeführt werden sollten. Um Synchronisierungsprobleme zu vermeiden, muss der Verwaltungscode zusammen mit dem Anwendungscode gesendet werden.
Um einmalige Verwaltungsprozesse in einer lokalen Bereitstellung auszuführen, verwenden die Entwickler einen direkten Shell-Befehl. In einer Produktionsbereitstellung könnten die Entwickler jedoch eine Methode zur Ausführung von Remote-Befehlen verwenden, z. B. Secure Shell (ssh.).
Darüber hinaus sollten Cloud-native Anwendungen effizientere Lösungen für die Ausführung einmaliger Prozesse integrieren. AWS Lambda-Funktionen werden beispielsweise bei Bedarf aufgerufen und erfordern nicht, dass Unternehmen bereitgestellte Server in Betrieb lassen. (Quelle)
Sie arbeiten in der IT oder interessieren sich für Themen rund um die IT? Dann besuchen Sie gerne unseren Blog für weitere Themen und folgen Sie uns auf LinkedIn und Facebook.