Die Twelve-Factor App und cloud-native Prinzipien

Woher die zwölf Faktoren kommen

2011 veröffentlichte Adam Wiggins, Mitgründer von Heroku, The Twelve-Factor App, ein kurzes Webdokument, das bündelte, was das Heroku-Team aus der Beobachtung sehr vieler Anwendungen gelernt hatte, die auf seiner Plattform gebaut, deployt und skaliert wurden. Die Methodik der Twelve-Factor App beschreibt Anwendungen, die sich aus deklarativen, automatisierten Schritten selbst einrichten, einen sauberen Vertrag mit der Plattform darunter haben, sodass sie überall laufen können, Entwicklung und Produktion nah genug beieinander halten, um kontinuierliches Deployment zu ermöglichen, und ohne Neuentwurf horizontal skalieren können.

Das Dokument ist älter als Docker (2013) und Kubernetes (2014), beschreibt aber fast genau den Vertrag, den diese Plattformen später durchgesetzt haben: Eine Anwendung ist eine Menge zustandsloser Prozesse, gebaut zu einem unveränderlichen Artefakt, von außen konfiguriert, die Logs in einen Stream schreibt und mit allem anderen über das Netzwerk spricht. Deshalb ist es bis heute das gemeinsame Vokabular für den Entwurf cloud-nativer Anwendungen. Im November 2024 gab Heroku bekannt, dass die Methodik nun Open Source ist und von einer Community aus Beitragenden mehrerer Unternehmen gepflegt wird, mit dem Ziel, sie an die heutige Praxis anzupassen; die ursprünglichen zwölf Faktoren bleiben der Bezugspunkt.

Die Faktoren betreffen die Beziehung der Anwendung zu ihrer Laufzeitplattform, nicht ihre interne Architektur. Ein modularer Monolith kann vollständig Twelve-Factor-konform sein; eine Menge von Microservices kann jeden Faktor verletzen. Sie ergänzen die Anliegen Deploybarkeit und Betreibbarkeit aus Kapitel 2 und die Prinzipien zu Skalierung und Zustandslosigkeit aus Kapitel 9.

Konfiguration, Secrets und Backing Services

Für den Konfigurationsfaktor gibt es einen einfachen Test: Könnte die Codebasis heute veröffentlicht werden, ohne eine einzige Zugangsinformation offenzulegen? Wenn nicht, ist Konfiguration in den Code gesickert. Die Trennung von Konfiguration und Code lässt ein Artefakt unverändert durch jede Umgebung wandern; das ist die Grundlage des Build-once-Prinzips in Abschnitt 10.5 (CI/CD und Deployment). Zur Konfiguration gehören Datenbank- und Service-URLs, Zugangsdaten und umgebungsspezifische Einstellungen; nicht dazu gehört die interne Verdrahtung, die überall gleich ist, etwa welche Klasse welche Route behandelt: Sie gehört in den Code.

Die ursprüngliche Empfehlung, Umgebungsvariablen zu verwenden, ist ungleichmäßig gealtert. Sie sind universell und sprachneutral, und Kubernetes, PaaS-Plattformen und Funktionen unterstützen sie alle. Aber die Umgebung eines Prozesses ist für Kindprozesse sichtbar, landet oft in Absturzberichten und Debugging-Seiten und lässt sich ohne Neustart nicht rotieren. Die heutige Praxis für Secrets ist, sie beim Start aus einem Secrets Manager abzurufen (AWS Secrets Manager, Azure Key Vault, Google Secret Manager, HashiCorp Vault oder OpenBao) oder sie als Dateien einzuhängen, die die Plattform aktualisieren kann, und noch besser, langlebige Secrets durch Workload Identity zu ersetzen, bei der die Plattform jedem Service automatisch kurzlebige Zugangsdaten gibt. Die Absicht des Faktors, Konfiguration außerhalb des Artefakts zu halten, ist unverändert.

Einen Backing Service als angebundene Ressource zu behandeln heißt, dass der Code die Bestelldatenbank, den Zahlungsanbieter und den Message Broker auf dieselbe Weise erreicht: über eine URL und Zugangsdaten, die beim Deployment bereitgestellt werden. Das macht Umgebungen kombinierbar und die Wiederherstellung schneller. Es macht Backing Services nicht wie von Zauberhand austauschbar; wer einen Message Broker durch einen anderen ersetzt, ändert die Zustellsemantik. Der hexagonale Stil aus Kapitel 5 ergänzt den Faktor: Die Konfiguration sagt, wo die Ressource ist, und ein Adapter hinter einem Port verbirgt, wie sie sich verhält.

Build, Release, Run

Der Faktor Build, Release, Run trennt drei Stufen, die oft verschwimmen. Die Build-Stufe macht aus einem Commit ein ausführbares Artefakt, heute meist ein Container-Image, das über seinen Digest identifiziert wird. Die Release-Stufe kombiniert dieses Artefakt mit der Konfiguration einer Umgebung und gibt dem Ergebnis eine Identität, etwa Release v42 des Bestellservice in der Produktion. Die Run-Stufe startet Prozesse aus einem Release. Releases sind unveränderlich: Eine Änderung an Code oder Konfiguration erzeugt ein neues Release, nie eine Bearbeitung eines bestehenden.

Diese Trennung macht Deployments langweilig. Niemand bearbeitet Dateien auf einem Server, also driften Server nicht auseinander; dasselbe Image, das im Staging getestet wurde, läuft in der Produktion, also hat ein Testergebnis Aussagekraft; und ein Rollback ist ein schneller, geübter Vorgang statt eines Notfall-Rebuilds. Sie ist auch ein Audit-Trail: Für jeden Zeitpunkt lässt sich genau sagen, welcher Code und welche Konfiguration liefen. Kubernetes führt eine Revisionshistorie der ReplicaSets jedes Deployments, PaaS-Plattformen nummerieren Releases, und GitOps (Abschnitt 10.4) macht die Git-Historie des Release-Repositorys zum Nachweis.

Prozesse, Nebenläufigkeit und Disposability

Zustandslose Shared-Nothing-Prozesse sind die Voraussetzung für fast alles andere in diesem Kapitel: horizontale Skalierung, Rolling Deployments, Autoscaling, das Ersetzen ausgefallener Knoten und die Verteilung über Zonen. Alles, was ein Prozess nur in seinem Speicher oder auf seiner lokalen Festplatte hält (die Session eines Nutzers, eine hochgeladene Datei, ein halb erstellter Bericht), geht verloren, wenn dieser Prozess ersetzt wird, und ist für die anderen Kopien unsichtbar. Kapitel 9 behandelt den Umgang mit Sessions ausführlich (Load Balancing, Zustandslosigkeit und Sessions). Zustand verschwindet nicht; er wandert in Backing Services, die dafür gemacht sind, ihn zu halten.

Der Nebenläufigkeitsfaktor ergänzt, dass verschiedene Arten von Arbeit als verschiedene Prozesstypen laufen sollten, die getrennt skalieren. In der Essenslieferplattform skaliert der Webprozess, der die Kunden-App bedient, mit der Anfragerate, während ein Worker-Prozess, der Bestellbestätigungen verschickt, mit der Queue-Länge skaliert und ein Consumer für Kurierstandorte mit dem Event-Durchsatz. Wer sie in einem Prozesstyp mischt, skaliert alle für den Bedarf eines einzigen.

Disposability verlangt, dass Prozesse in Sekunden starten und sauber stoppen. Bei SIGTERM nimmt ein Webprozess keine Verbindungen mehr an und beendet laufende Anfragen; ein Worker gibt seine aktuelle Nachricht an die Queue zurück oder schließt sie innerhalb der Karenzzeit ab. Weil Prozesse auch ohne Vorwarnung sterben können (ein Knotenausfall, ein Abbruch wegen Speichermangels), muss Arbeit gefahrlos wiederholbar sein: idempotente Nachrichtenverarbeitung wie in der ereignisgesteuerten Architektur und Jobs, die an Checkpoints fortsetzen. George Candea und Armando Fox trieben die Idee 2003 mit Crash-only Software auf die Spitze, die nur eine Art zu stoppen kennt (den Absturz) und eine Art zu starten (die Wiederherstellung), sodass der Wiederherstellungspfad ständig geübt statt erst während eines Incidents entdeckt wird.

Dev/Prod-Parität, Logs und Admin-Prozesse

Der Originaltext benennt drei Lücken zwischen Entwicklung und Produktion: Zeit (Code, der Wochen vor seinem Deployment geschrieben wird), Personal (Entwickler schreiben ihn, der Betrieb deployt ihn) und Tools (SQLite auf dem Laptop, PostgreSQL in der Produktion). Continuous Delivery schließt die erste, Teams, die betreiben, was sie bauen, schließen die zweite, und Container schließen einen großen Teil der dritten: Eine Entwicklerin kann dieselbe PostgreSQL-Version, denselben Message Broker und denselben Cache lokal ausführen, und Tools wie Testcontainers starten echte Abhängigkeiten in Integrationstests. Perfekte Parität ist weder bezahlbar noch nötig; am wichtigsten ist, dieselben Arten und Versionen von Backing Services zu verwenden, denn dort liegen die überraschenden Unterschiede.

Logs als Event-Streams bedeutet, dass die Anwendung jedes Ereignis auf die Standardausgabe schreibt und Speicherung, Rotation und Weiterleitung der Plattform überlässt. Das ist weiterhin richtig, mit zwei heutigen Ergänzungen: Logs sollten strukturiert sein (zum Beispiel JSON mit einheitlichen Feldnamen und einer Anfrage- oder Trace-ID), und Logs sind eines von drei Signalen, neben Metriken und Traces, die ein System beobachtbar machen (Observability). Das Log-Volumen ist außerdem ein echter Kostentreiber; Abschnitt 10.8 kommt darauf zurück.

Admin-Prozesse wie Datenbankmigrationen, Datenreparaturen und einmalige Berichte sollten mit demselben Release (Code und Konfiguration) wie die Anwendung laufen, als separate Prozesse. In Kubernetes ist das typischerweise ein Job, den die Pipeline ausführt, bevor die neue Version ausgerollt wird. Migrationen brauchen besondere Sorgfalt: Sie müssen sowohl mit der alten als auch mit der neuen Codeversion kompatibel sein, die nebeneinander laufen; das ist die Disziplin Expand and Contract der Schemaevolution.

Über die zwölf Faktoren hinaus

Die zwölf Faktoren waren nie als vollständig gedacht, und spätere Autoren haben sie erweitert. Kevin Hoffmans Beyond the Twelve-Factor App (O’Reilly, 2016) erweiterte die Liste auf fünfzehn und ergänzte API First (den Vertrag vor der Implementierung entwerfen), Telemetrie (Metriken, Health und Tracing einbauen) sowie Authentifizierung und Autorisierung (Sicherheit als Entwurfsanliegen von Anfang an). Die heutige Praxis ergänzt vier Themen, die jede cloud-native Anwendung erfüllen sollte.

Disposability, ernst genommen. Darauf auslegen, jederzeit beendet zu werden: idempotente Operationen, kurze Anfrage-Timeouts, begrenzte Startzeit, geordnetes Leerlaufen (Drain) und kein einzelner Prozess, dessen Verlust ins Gewicht fällt. Unveränderlichkeit. Nie einen laufenden Container oder Server patchen; ein neues Image bauen und ihn ersetzen (Abschnitt 10.4 zu Immutable Infrastructure). So lässt sich jede laufende Instanz auf einen Commit zurückführen, und Drift entfällt. Observability. Strukturierte Logs, Metriken und Traces über einen Standard wie OpenTelemetry ausgeben, Health-Endpoints bereitstellen, die den eigenen Zustand des Prozesses widerspiegeln, und den Trace-Kontext über Aufrufe hinweg weitergeben, damit der Betrieb Fragen beantworten kann, die er nicht vorhergesehen hat. Sicherheit. Wo möglich als Nicht-Root-Benutzer mit schreibgeschütztem Dateisystem laufen; Zugangsdaten über Workload Identity statt über langlebige Schlüssel beziehen; für jeden Backing Service das Prinzip der geringsten Rechte anwenden; und aus minimalen, gescannten, signierten Images bauen (Sicherheit der Software-Lieferkette).