Die Twelve-Factor App – nur etwas für die Cloud?

Die Vorzüge von Versionskontrollsystemen sind bekannt, sodass der Einsatz eben solcher niemanden mehr verschreckt. Entwicklerteams, verteilt oder nicht, können sich ihre Arbeit ohne Git, SVN oder Mercurial wahrscheinlich gar nicht vorstellen. Auch werden die meisten zustimmen können, dass aus ein und demselben Repository auf alle Umgebungen ausgerollt wird. Schließlich soll auf allen Umgebungen dieselbe Software laufen, warum nicht dieselbe Quelle nehmen?

In der Beschreibung dieses Faktors steht aber auch, dass eine Applikation aus genau einem Repository bestehen soll. Selbstgebaute Abhängigkeiten sollen also entweder so archiviert sein, dass sie durch den Dependency Manager automatisiert aufgelöst werden können, oder schlichtweg im selben Repository vorhanden sein.

Außerdem besagt dieser Faktor, dass derselbe Quelltext auf alle Umgebungen ausgerollt werden soll. Daraus folgt, dass für die Produktivumgebung dasselbe Artefakt benutzt werden soll, wie für alle anderen Umgebungen. Spätestens hier kann es zu Problemen in manch einem Projekt kommen. Doch wie diese behandelt werden können, wird in den folgenden Faktoren diskutiert.
Faktor 1, die Codebase, sollte also kein Problem für Monolithen darstellen.

Die Konfiguration der Applikation besteht aus allem, was sich zwischen Deploys und Umgebungen ändern könnte. Dies beinhaltet unter Anderem Zugangsdaten zu Fremdsystemen, Zugriffsmöglichkeiten auf Drittdienste und Werte, die sich pro Deploy ändern. Um Standardwerte anzugeben, die sich unter Umständen nur auf bestimmten Umgebungen ändern müssen, können diese entweder mit in die Software einkompiliert werden, oder in Konfigurationsdateien angegeben und später über beispielsweise Umgebungsvariablen überschrieben werden.

Ein gutes Beispiel für solche Mechanismen kann der Konfigurationsmechanismus von Spring Boot Applikationen dienen. Im Kapitel „Externalized Configuration“ wird beschrieben, in welcher Reihenfolge Konfigurationswerte, die man üblicherweise in der `application.properties` oder `application.yml` anlegt, von außen überschrieben werden können.

Mithilfe dieses Mechanismus kann die Software so programmiert werden, dass alle Standardwerte, die man in der zentralen Konfigurationsdatei eingegeben hat, für die lokale Entwicklungsumgebung der Programmierer gültig sind. Sowie die Software dann ausgeliefert wird, kann über Umgebungsvariablen, Kommandozeilenparameter oder Java System Properties, um nur ein paar zu nennen, die Applikation für das jeweilige Einsatzgebiet passend konfiguriert werden.
Diese Vorgehensweise ist dabei vollkommen programmiersprachen- und betriebssystemunabhängig, bringt in Cloud-Applikationen kritische Vorteile, kann aber auch bei monolithischen Programmen sehr große Mehrwerte generieren.

Als Backing service bezeichnen die Autoren der twelve factor app alle Dienste, die eine Applikation über das Netzwerk konsumieren. Dabei unterscheiden sie zwischen Diensten, die dieselben Administratoren betreiben, die auch die Applikation betreuen, und Diensten, die von Dritten bereitgestellt werden. Als Beispiele können hier die applikationseigene Datenbank auf der einen Seite und Binärdatenspeicher wie Amazons S3 oder SMTP-Dienste auf der anderen Seite dienen.

Ein Softwareprojekt, das den zwölf Faktoren genügen möchte, behandelt diese Dienste, egal von wem sie betreut werden, als lose angebundene Ressource. Man soll dazu in der Lage sein eine lokal angelegte Datenbank, die auf einer benachbarten VM liegt, durch eine Datenbank eines Cloudanbieters austauschen zu können. Dies soll vor allem der dritte Faktor, Config, ermöglichen: sämtliche Zugangsdaten liegen in der Konfiguration vor und können von den Betreibern der Software ausgetauscht werden. Die Applikation kümmert sich lediglich um die technische Natur der Netzwerkverbindung und zieht die Konfigurationsdaten heran, um sich zum Service zu verbinden. Der Service wird nur noch als angeschlossene Ressource behandelt. Dieser Faktor spielt im Cloudumfeld eine besondere Rolle, da hier viel schneller über Netzwerkgrenzen hinweg kommuniziert wird. Der Gedanke, dass ein zu konsumierender Dienst nur über eine nicht permanent verfügbare Schnittstelle erreichbar ist, die zusätzlich Latenzen in die Kommunikation einbringen kann, muss stets im Hinterkopf vorhanden sein.

Bei monolithisch aufgebauten Systemen ist dieser vorhergesagte Wandel im Betriebsumfeld nicht unbedingt gegeben – die Software muss schlicht nicht unbedingt das gleiche Maß an Flexibilität aufweisen. Nichtsdestotrotz kostet es keinen Mehraufwand,++ und ist als Best Practice angesehen, die Schnittstellen des Systems so aufzubauen, dass man sich lediglich auf die technisch garantierten Eigenschaften der Technologie verlässt, statt beispielsweise davon auszugehen, dass die Datenbank immer auf demselben Host liegt und somit Latenzen nahe null sind.

Laut der 12 Factor App ist die Build Stage dafür zuständig, den Code eines Repositories in ein ausführbares Artefakt umzuwandeln, auch Build genannt. Die Release Stage kombiniert das Artefakt mit der Konfiguration eines Deployziels und erstellt damit ein Release. Die Run Stage schlussendlich führt das Release aus. Darüber hinaus wird definiert, dass ein Release eine einzigartige Bezeichnung besitzt, genannt Release ID. Ein Schema wird nicht vorgegeben, stattdessen werden Timestamps oder hochzählende Zahlen empfohlen.

Dieses Vorgehen ermöglicht, dass derselbe Stand eines Repositories auf allen Umgebungen eingesetzt wird und verdeutlicht nochmals die Wichtigkeit des dritten Faktors Konfiguration. Außerdem wird so bereits eine grobe Struktur einer Buildpipeline definiert und der Deployprozess angeschnitten. Spätestens hier kriegen wir einen ersten Geschmack davon, dass erfahrene Softwareentwickler an diesem Dokument gearbeitet haben. Jedes Kind kriegt einen Namen und eine klar umschnittene Aufgabe zugewiesen. Altbekannte Best Practices, die in sich bereits destilliertes Wissen darstellen, werden Prozessschritten zugeordnet und beweisen in ihrer Einfachheit Eleganz.

In manch einer Technologie oder bestehenden Legacysystemen wird sich die Funktion einer Release Stage unter Umständen nicht innerhalb kurzer Zeit umsetzen, doch auf lange Zeit wird sich eine solche Struktur positiv auf Faktoren wie die Stabilität der Releases auswirken – und das nicht nur im Cloudumfeld.

Die Applikation soll in der Run Stage als einer oder mehrere Prozesse ausgeführt werden. Im einfachsten Fall bedeutet dies, dass die Applikation ein simples Script ist, welches über die Kommandozeile ausgeführt wird.
Der wichtigste Aspekt jedoch ist, dass solche Prozesse zustandslos sind und keine Daten untereinander teilen.

Zustandslos zu sein bedeutet, dass Prozesse über mehrere Läufe hinweg immer wieder komplett terminieren und somit keine Daten „flüchtig“ im Arbeitsspeicher speichern. Sämtliche Daten, die zu persistieren sind, müssen in einem Backing Service, beispielsweise einer Datenbank, abgelegt werden. Untereinander keine Daten zu teilen bedeutet, dass Prozesse voneinander unabhängig arbeiten können und davon ausgehen müssen, isoliert von anderen Prozessen ausgeführt zu werden. Die einzige Art, wie Prozesse Daten austauschen können, ist mit Backing Services zu kommunizieren.

Sind diese Kriterien erfüllt, hat man nicht nur eine klare Applikationsstruktur erreicht, sondern kann wichtige Verarbeitungsschritte, welche als Prozesse definiert sind, parallelisiert ausführen um horizontale Skalierbarkeit zu erreichen.

Dieser Faktor verstärkt nochmals Faktor VI. Prozesse sollen in der Architektur der Applikation als Objekte erster Klasse angesehen werden. Sie bilden das primäre Bauteil der Anwendungsstruktur. Es wird vorgeschlagen, Prozesse nach Typ zu gruppieren, beispielsweise Web-Prozesse die HTTP-Anfragen verarbeiten oder Hintergrundprozesse die regelmäßige Aufgaben abarbeiten. Solche Prozesse können selber Kindprozesse starten, können so aber nur eine beschränkte Menge skalieren.

Der größte Vorteil liegt sicherlich darin, dass über dieses Prozessmodell horizontale Skalierbarkeit auf Applikationsebene erreicht werden kann. Wurden die vorgeschriebenen Bedingungen eingehalten, kann die Parallelität ohne Probleme erhöht werden, um mehr Aufgaben abzuarbeiten.

Im Cloudumfeld bedeutet dies meistens, dass mehr virtuelle Maschinen herangezogen werden oder mehr Container im Cluster hochgefahren werden. Beim Monolithen kann dies bedeuten, dass eine Konfiguration angepasst wird, sodass beispielsweise mehr Hintergrundprozesse gestartet werden. Hier ist die Skalierbarkeit über mehrere Maschinen vielleicht nicht unbedingt gegeben, jedoch kann dann einfacher mit einem Upgrade der Hardware gearbeitet werden.

Prozesse, die den oben genannten Bedingungen genügen und Teil einer 12 Factor App sind, können nach Belieben gestartet und gestoppt werden, damit eine schnelle Skalierbarkeit und Anpassbarkeit, beispielsweise durch geänderte Konfiguration, erreicht werden kann. Außerdem sollen sie schnell, innerhalb weniger Sekunden, hoch- und wieder runterfahren können und das Prozessmodell soll einen abrupten Prozessstop, beispielsweise wenn der Host abstürzt, handhaben können.

Diese Liste an Anforderungen ist ein klares Eingeständnis an die Bedingungen im Cloudumfeld. Während ein schneller Applikationsstart auch einem Monolithen sehr gut zu Gesicht steht und Fehler in der unterliegenden Hardware des Hosts oder das sprichwörtliche Ziehen am Stromstecker im besten Fall nie zum katastrophalen Prozessschaden führen sollte, sind die Bedingungen im On-Premise-Bereich meistens als stabiler anzusehen.
Nichtsdestotrotz zeigt dieser Punkt einige, wenn auch selbstverständliche, erstrebenswerte Ziele auf.

Auch im bestgetesteten Projekt das die strengsten Qualitätsprozesse besitzt, ist es manchmal für Entwickler und Betreiber hilfreich, über mitgelieferte Tools der Applikation ins laufende System einzugreifen. Die Autoren empfehlen auch für diese administrativen Prozesse auf das Prozessmodell und alle weiteren Faktoren zu achten. So ist es zum Beispiel empfehlenswert für administrative Prozesse das Buildtool der jeweiligen Technologie zu nutzen, in Ruby beispielsweise rake oder rails, um die gleichen Vorteile in Hinblick auf Dependencies und Isolation zu erhalten, wie bei der Applikation selbst.

Als Alternative zum Buildtool werden explizit REPLs genannt. Sprachen wie Python oder Clojure unterstützen diese Art Technologie schon seit langer Zeit, Java auch schon seit einigen Versionen. Die Fähgikeiten unterscheiden sich aber relativ stark und die Nutzung ist sicherlich nicht für jede Person zugänglich.