The Twelve-Factor App

Die Twelve-Factor App Methode lässt sich auf Software anwenden, die in jeder beliebigen Programmiersprache (C#, Java, TypeScript, PHP, Python, …) entwickelt wird. Die Methode unterstützt zudem eine beliebige Kombination von Diensten (Datenbank, Message Queue, Cache, …). Die Konzepte können ebenfalls auf jedes beliebige Framework, wie das Web-Framework Angular oder das Mobile-Framework Flutter, angewendet werden.

Wir haben die 12 Faktoren in einer Checkliste zusammengefasst:

1. Codebasis

Änderungen am Code sollen mit Hilfe von Versionsverwaltung getrackt werden. Mit Tools wie Git wird die Zusammenarbeit im Team erst ermöglicht. Dabei hat jeder Entwickler seine eigene Version des Codes und der Single-Point-of-Truth ist der Code in der Versionsverwaltung (repository). Für einen Release der Software wird der Code im Repository dann kompiliert, getestet und in der Cloud bereitgestellt.

2. Abhängigkeiten

Softwareabhängigkeiten (dependencies) sind externe Bibliotheken, die in vielen verschiedenen Apps verwendet werden können. Falls externe Bibliotheken verwendet werden, müssen diese explizit in einem „package manager“ spezifiziert werden. Es darf nie die Annahme getroffen werden das eine Abhängigkeit auf einem System schon vorhanden ist.

3. Konfiguration

Die Konfiguration einer App ist alles was sich wahrscheinlich zwischen verschiedenen Bereitstellungen (dev, test, staging, production) verändert. Konfigurationen dürfen nicht als Konstanten im Code gespeichert werden. Konfiguration und Code müssen immer strikt getrennt sein. Am besten wird die Konfiguration in Umgebungsvariablen (env) gespeichert. Dadurch wird ausgeschlossen, dass versehentlich Zugangsdaten in die Versionsverwaltung eingecheckt werden 😉

4. Unterstützende Dienste

Ein unterstützender Dienst ist jeglicher Dienst, den die App über das Netzwerk abruft. Dazu zählen zum Beispiel Datenspeicher (SQL/No-SQL Datenbanken, Objektspeicher), Message-Queue Systeme (RabbitMQ, Google Cloud Pub/Sub, …) oder SMTP-Dienste für das Senden von E-Mails (Sendgrid, Mailchimp, …). Jeder Dienst soll über eine URL, die in der Konfiguration gespeichert ist, erreichbar sein. Wenn z.B. eine Datenbank ausgetauscht wird, soll keine Änderung am Code erfolgen. Änderungen sollen lediglich über die Konfiguration gemacht werden.

5. Build, Release, Run

Jede Codeänderung muss diese drei Phasen durchlaufen. Es soll nicht möglich sein, Änderungen am Code während der Laufzeit zu machen. Um diese Phasen zu automatisieren soll ein CI/CD Tool (Travis CI, Jenkins, Bitrise, …) verwendet werden. Neue Build‘s werden durch die Entwickler der App ausgelöst, indem sie neuen Code in die Versionsverwaltung einchecken. Somit ist jeder Build eindeutig auf eine bestimmte Version des Codes zurückzuführen.

6. Prozesse

Die App sollte auf einer „Shared Nothing“ Architektur aufgebaut werden. D.h. die App ist unabhängig von anderen Apps und kann einen eigenen Prozessor und Speicher verwenden. Ein Abstürzen der Applikation darf nie dazu führen das andere Services beeinträchtigt werden. Alle Daten, die von der App verwendet werden, müssen in einer Datenbank gespeichert werden. Dies garantiert die Skalierung unter hoher Last, da nahezu unbegrenzt neue Instanzen der App gestartet werden können. 🚀

7. Bindung an Ports

Eine Zwölf-Faktoren-App soll nicht an einen Anwendungscontainer wie Apache Tomcat gebunden sein. Die Anwendung soll einen eigenen Web Server o.ä. integrieren, damit diese über einen bestimmten Port erreichbar ist.

8. Nebenläufigkeit

Die Anwendung soll anhand von Prozesstypen wie Hintergrund-, Web- und Worker-Prozessen in unabhängige Prozesse aufgeteilt werden. Somit kann eine einfache Skalierung garantiert werden. Falls ein Teil der Anwendung eine hohe Auslastung widerfährt, können von diesem Prozesstyp mehrere Instanzen gestartet werden.

9. Einweggebrauch

Prozesse einer App sollen schnell gestartet und gestoppt werden können. Dies erleichtert schnelles skalieren während Belastungsspitzen und ein schnelles Bereitstellen von Code. Die Startzeit eines Prozesses sollte so gering wie möglich sein. Zusätzlich sollten Prozesse auch schnell gestoppt werden können, damit sie die verwendeten Ressourcen wieder für andere Services zur Verfügung stellen.

10. Dev-Prod-Vergleichbarkeit

Die Entwicklungsumgebung sollte so sehr wie möglich der Produktionsumgebung ähneln. Unterschiede zwischen den verwendeten Diensten können Inkompatibilitäten verursachen, die erst beim Bereitstellen in der Produktionsumgebung erkennbar werden. Eine Zwölf-Faktoren-App ist auf Continuous Deployment ausgelegt, indem sie die Unterschiede zwischen Entwicklung und Umgebung klein hält.

11. Logs

Logs sind ein Datenstrom von Ereignissen, die das Verhalten einer laufenden App sichtbar machen. Eine Zwölf-Faktoren-App soll sich nicht selbst um Logs kümmern und diese z.B. in eine Datei schreiben. Es sollte ein separater Service verwendet werden, der diese Logs verwaltet und übersichtlich darstellt.

12. Admin-Prozesse

Verwaltungsprozesse wie das Erstellen von Berichten oder die Migration von Datenbankschemas müssen von der Anwendung selbst entkoppelt sein. Die Ausführung eines Admin-Prozess darf die eigentliche Anwendung in keiner Weise beeinflussen.

Das Zwölf-Faktoren-Modell deckt also viele Aspekte der Entwicklung einer Anwendung ab. Das Modell ist gut dazu geeignet, zukunftsorientierte Anwendungen für die Cloud zu entwickeln. 👍

Je nach Anwendungsfall müssen die Methoden angepasst werden, für Internet-of-Things Anwendungen gelten natürlich andere Regeln wie für Web-Anwendungen. Dennoch stellt diese Methode eine gute Basis dar, um einen Überblick an die Anforderungen moderner App-Entwicklung zu bekommen.

FORTIX hat die Methode für Zwölf-Faktoren-Anwendungen verinnerlicht und entwickelt für Sie moderne Software die nahtlos skaliert werden kann. 💪💻

Dabei halten wir uns an eine Vielzahl von Best Practices, um die Wartbarkeit und Erweiterbarkeit des Codes zu verbessern. Wir entwickeln Cloud native und Internet-of-Things (IoT) Anwendungen die auf jedem beliebigen Cloud Provider (AWS, Azure, Google Cloud, Software AG, …) ausgeführt werden können.

Wenn Sie mehr über den Entwicklungsprozess bei FORTIX erfahren wollen können Sie uns gerne kontaktieren. Wir freuen uns! 🎉