12/15-Factor-App und Cloud-native Standards: Was deine Anwendung für den Betrieb auf Kubernetes mitbringen sollte

Fast jede Anwendung läuft heute irgendwann in einem Container, und fast jede Diskussion über „cloud-native“ landet früher oder später bei derselben Frage: Was muss eine Anwendung eigentlich mitbringen, damit eine Plattform sie zuverlässig betreiben kann? Die bekannteste Antwort darauf ist die Twelve-Factor-App, ergänzt um drei Faktoren zur 12/15-Factor-App. Dieser Artikel ordnet die Faktoren ein, zeigt, wie das CNCF Cloud Native Maturity Model sie in einen größeren Rahmen setzt, und fasst zusammen, worauf es beim Betrieb auf Kubernetes in der Praxis ankommt.

Warum es die zwölf Faktoren gibt

Die Twelve-Factor-App entstand Anfang der 2010er-Jahre bei Heroku, formuliert von Adam Wiggins. Er und sein Team hatten hunderte Anwendungen auf einer gemeinsamen Plattform betrieben und dabei immer dieselben Muster gesehen: Anwendungen, die sich nicht automatisiert ausliefern ließen, weil Konfiguration im Code lag. Anwendungen, die nicht horizontal skalierten, weil sie lokalen Zustand hielten. Anwendungen, die in Produktion anders liefen als auf dem Entwicklungsrechner.

Die zwölf Faktoren sind die Antwort darauf. Sie beschreiben keine Technologie und keinen Stack, sondern eine Verantwortungsteilung zwischen Anwendung und Laufzeitumgebung. Sie legen fest, was eine Plattform von einer Anwendung erwarten darf und was die Anwendung im Gegenzug von der Plattform erwarten kann. Erfüllt die Anwendung diese Erwartungen, kann die Plattform sie starten, stoppen, vervielfachen und verschieben, ohne die Anwendung selbst zu kennen. Genau darauf beruht alles, was heute unter Container-Orchestrierung läuft.

Die zwölf Faktoren im Überblick

In der ursprünglichen Reihenfolge nach 12factor.net, jeweils mit dem Kern des Prinzips:

1. Codebase: Eine Codebasis pro Anwendung, versioniert, aus der beliebig viele Deployments entstehen.
2. Dependencies: Abhängigkeiten werden explizit deklariert und isoliert. Nichts wird aus der Systemumgebung vorausgesetzt.
3. Config: Alles, was sich zwischen Umgebungen unterscheidet, liegt in der Umgebung, nicht im Code.
4. Backing Services: Datenbanken, Queues und Caches sind angehängte Ressourcen, austauschbar über Konfiguration.
5. Build, Release, Run: Die drei Phasen sind strikt getrennt. Ein Release ist unveränderlich und eindeutig identifizierbar.
6. Processes: Die Anwendung läuft als ein oder mehrere zustandslose Prozesse. Zustand gehört in einen Backing Service.
7. Port Binding: Die Anwendung exportiert ihren Dienst selbst über einen Port, statt einen externen Webserver vorauszusetzen.
8. Concurrency: Skalierung erfolgt horizontal über zusätzliche Prozesse, nicht über größere Maschinen.
9. Disposability: Prozesse starten schnell und fahren sauber herunter. Sie sind jederzeit ersetzbar.
10. Dev/Prod Parity: Entwicklung, Staging und Produktion bleiben sich so ähnlich wie möglich.
11. Logs: Logs sind ein Ereignisstrom nach stdout. Die Anwendung schreibt keine Logdateien und rotiert nichts.
12. Admin Processes: Einmalige Aufgaben wie Migrationen laufen als eigener Prozess gegen denselben Release.

Diese Liste ist rund fünfzehn Jahre alt und in weiten Teilen unverändert gültig. Wer heute ein Container-Image baut und es in Kubernetes deployt, setzt die meisten dieser Punkte implizit um, ob bewusst oder nicht.

Was sich seitdem verändert hat

Die Twelve-Factor-App beschreibt eine einzelne Anwendung auf einer PaaS. Das war damals der Referenzfall. Seitdem hat sich der Betrieb in drei Richtungen verschoben.

Erstens wurde aus der einen Anwendung ein verteiltes System. Wo früher ein Monolith gegen eine Datenbank lief, kommunizieren heute Dutzende Services über das Netz. Die Schnittstelle zwischen ihnen ist zum kritischen Artefakt geworden, das ursprüngliche Modell sagt dazu nichts.

Zweitens ist der Betrieb selbst deklarativ geworden. Kubernetes erwartet Health Probes, Resource Requests, Graceful Shutdown und definierte Terminationsfristen. Das sind konkrete technische Anforderungen, die über das ursprüngliche „schnell starten, sauber beenden“ hinausgehen.

Drittens ist Sicherheit vom Randthema zur Grundvoraussetzung geworden. In einem verteilten System gibt es kein vertrauenswürdiges internes Netz mehr, in dem Service-zu-Service-Aufrufe ungeprüft passieren dürfen.

Die drei zusätzlichen Faktoren

Kevin Hoffman hat diese Lücken 2016 in Beyond the Twelve-Factor App geschlossen. Er ordnet die bestehenden Faktoren neu, schärft einzelne Formulierungen und ergänzt drei Punkte. Wenn wir von der 12/15-Factor-App sprechen, meinen wir die zwölf Faktoren plus diese drei.

13. API First

Die Schnittstelle wird entworfen, bevor die Implementierung beginnt. Ein versionierter API-Contract, etwa als OpenAPI- oder Protobuf-Definition, ist das erste Artefakt eines Services, nicht das Nebenprodukt seiner Fertigstellung.

Der praktische Nutzen liegt in der Entkopplung: Konsumierende Teams können gegen Mocks entwickeln, Breaking Changes werden im Review sichtbar statt in Produktion, und Contract Tests lassen sich in die Pipeline hängen. In einer Architektur aus vielen Services ist das der Unterschied zwischen unabhängigen Teams und einem verteilten Monolithen.

14. Telemetry

Der ursprüngliche Log-Faktor betrachtet Logs als Ereignisstrom. Das ist notwendig, aber nicht ausreichend. Hoffman erweitert den Blick auf drei Datenarten: Anwendungsmetriken wie Durchsatz und Fehlerraten, Zustandsmetriken wie Health und Verfügbarkeit, sowie Domänenereignisse aus der Fachlogik.

Der Kern des Faktors ist eine Perspektivfrage. Bei einer Handvoll Server kann man sich auf ein System aufschalten und nachsehen. Bei hunderten kurzlebigen Pods geht das nicht mehr. Telemetrie muss deshalb Teil der Anwendung sein, nicht etwas, das später von außen darübergelegt wird.

Was die Anwendung nicht von sich aus preisgibt, kann keine Plattform nachträglich sichtbar machen.

In heutiger Praxis heißt das: strukturierte Logs, ein Prometheus-kompatibler Metrik-Endpunkt, verteiltes Tracing mit durchgereichten Kontext-Headern. OpenTelemetry hat sich dafür als Standard etabliert.

15. Authentication and Authorization

Sicherheit ist kein Faktor, den man nachrüstet. Jeder Zugriff, auch der zwischen zwei internen Services, wird authentifiziert und autorisiert. Identitäten sind kurzlebig, Berechtigungen sind explizit, Secrets liegen niemals im Image oder im Repository.

Auf einer Kubernetes-Plattform bedeutet das ein Zusammenspiel mehrerer Ebenen: RBAC für den Cluster-Zugriff, ein zentrales Secrets Management, mTLS für die Service-zu-Service-Kommunikation und Policy Enforcement, das unsichere Konfigurationen ablehnt, bevor sie Wirkung entfalten.

Cloud-native Standards über die Faktoren hinaus

Die 15 Faktoren beschreiben die Anwendung. Wie sich Plattform, Auslieferung und Sicherheit rund um diese Anwendung entwickeln, beschreibt das Cloud Native Maturity Model der CNCF. Es ist herstellerneutral, nennt ausschließlich Projekte, die in der CNCF den Status graduated oder incubating haben, und betrachtet fünf Aspekte: People, Process, Policy, Technology und Business Outcomes. Für jeden Aspekt beschreibt es fünf Stufen, von Level 1 Build über Operate, Scale und Improve bis Level 5 Adapt.

Für die Frage, ob eine Anwendung betreibbar ist, zählt der Aspekt Technology. Er beschreibt unter anderem Anwendungsmuster, Container- und Runtime-Management, Release und Betrieb, Tests und Fehlererkennung sowie Sicherheit und Policies. Spätestens mit dem Schritt in Produktion (Level 2) erwartet das Modell Dinge, die sich direkt aus den Faktoren ableiten lassen:

• Pods sind kurzlebig. Verfügbarkeit entsteht durch mehrere Replicas, PodDisruptionBudgets und TopologySpreadConstraints, nicht durch einen besonders stabilen einzelnen Pod.
• Konfiguration ist externalisiert. ConfigMaps und Secrets statt eingebauter Konfiguration im Image.
• Probes sind aussagekräftig. Eine Readiness-Probe prüft, ob die Anwendung wirklich Anfragen bedienen kann, nicht nur, ob der Prozess läuft.
• Die Lieferkette ist nachvollziehbar. Versionierte Images, Image Scanning und eine SBOM je Release.
• Ressourcen sind bemessen. Resource Requests und Limits sind gesetzt und passen zum tatsächlichen Verbrauch.

Die Plattformseite dieser Stufen lässt sich standardisieren: GitOps, Observability, Secrets Management, Policy Enforcement und Backup & Recovery sehen bei fast allen Unternehmen gleich aus. Die Anwendungsseite nicht. Sie entscheidet, wie viel eine Plattform tatsächlich abnehmen kann.

Was das für den Betrieb konkret heißt

Aus den Faktoren und dem Maturity Model ergibt sich ein überschaubarer Satz an Merkmalen. Keine Anwendung muss alle von Anfang an erfüllen, und auch eine weniger cloud-native Anwendung lässt sich auf Kubernetes betreiben. Jeder erfüllte Punkt sorgt aber dafür, dass Updates, Node-Rotationen und Skalierung mit weniger Handarbeit und ohne Störung für deine Nutzer laufen.

Was eine betreibbare Anwendung auszeichnet

• Ein unveränderliches Artefakt: versionierte OCI-Images, dieselbe Image-Version in allen Umgebungen, keine latest- oder anderen Floating-Tags.
• Konfiguration aus der Umgebung, Secrets aus dem Secrets Management: keine Zugangsdaten im Image, im Repository oder in Logs.
• Zustand in Backing Services: Datenbanken, Object Storage und Caches statt Sessions im Arbeitsspeicher oder Dateien im lokalen Dateisystem des Pods.
• Sauberer Lebenszyklus: aussagekräftige Liveness- und Readiness-Probes, Graceful Shutdown auf SIGTERM, gesetzte Resource Requests und Limits.
• Beobachtbarkeit von innen: Logs nach stdout, möglichst strukturiert und ohne personenbezogene Daten oder Zugangsdaten im Klartext, dazu Metriken der Anwendung.
• Least Privilege: Betrieb als non-root, ohne privilegierte Container.

Wenn jemand anderes den Betrieb der Anwendung übernimmt

Anders sieht es aus, wenn nicht dein Team, sondern ein externer Dienstleister die Anwendung rund um die Uhr betreuen soll. Dann muss sie nicht nur betreibbar, sondern auch von außen beherrschbar sein, ohne dass jemand ihr Innenleben kennt. Bei kloudease ist das SREaaS: Wir übernehmen Alarmierung und Erstreaktion für deine Anwendung. Die 12/15-Factor-Prinzipien sind dafür Voraussetzung, und es kommen unter anderem hinzu:

• Deployment über Helm Charts mit vollständiger Rollback-Möglichkeit, rollbackfähige APIs und Datenbankschemata nach dem Expand/Contract-Prinzip
• zustandslose, HPA-fähige Deployments mit mehreren Replicas und PodDisruptionBudget
• Prometheus-kompatible Metriken für Alarmierung und Fehlerraten sowie ein fachlicher Health-Endpunkt
• strukturierte Logs (JSON) mit Korrelations-ID
• ein abgestimmtes Alert-Regelwerk mit Runbook je kritischem Alarm
• eine SBOM je Release

Die vollständige Liste steht im Dokument SREaaS. Geprüft wird sie vor dem Start in einer Conformance-Prüfung. Wenn du vorher wissen willst, wo deine Anwendung steht, ist das Paket Production Readiness der passende Einstieg.

Was davon in der Praxis den Unterschied macht

Nicht alle Punkte sind gleich schwer. Die meisten ergeben sich ohnehin, sobald ein Team konsequent containerisiert. Drei sehen wir dagegen regelmäßig als echte Hürde, wenn Anwendungen auf eine Kubernetes-Plattform migrieren.

Zustandslosigkeit ist selten vollständig umgesetzt

Session-Daten im Arbeitsspeicher, hochgeladene Dateien im lokalen Dateisystem, ein Cron-Job, der nur auf genau einer Instanz laufen darf: Solche Reste verhindern, dass horizontal skaliert oder ein Pod einfach neu gestartet werden kann. Sie fallen im Normalbetrieb nicht auf und werden beim ersten Node-Ausfall zum Vorfall.

Konfiguration und Secrets werden vermischt

Konfiguration aus der Umgebung zu lesen ist verstanden. Dass Zugangsdaten einem anderen Lebenszyklus folgen als Feature-Flags, oft nicht. Secrets brauchen Rotation, Auditierbarkeit und ein Backing System, das nicht dasselbe Git-Repository ist.

Sauberes Herunterfahren wird übersehen

Kubernetes sendet SIGTERM und wartet eine begrenzte Zeit. Anwendungen, die dieses Signal ignorieren, brechen laufende Anfragen ab. Jedes Deployment, jedes Rescheduling und jede Node-Rotation erzeugt dann Fehler, die in keiner Metrik als Ursache auftauchen.

Eine kurze Selbsteinschätzung

Die folgenden Fragen lassen sich ohne Analysewerkzeug beantworten und zeigen recht zuverlässig, wo eine Anwendung steht:

• Lässt sich eine beliebige Instanz jederzeit beenden, ohne dass ein Nutzer es bemerkt?
• Läuft dasselbe Image in allen Umgebungen, unterschieden nur durch Konfiguration?
• Existiert die API-Definition unabhängig vom Code, versioniert und reviewbar?
• Ist bei einem Fehler in Produktion ohne Zugriff auf den Container nachvollziehbar, was passiert ist?
• Wird ein Aufruf zwischen zwei internen Services geprüft, oder wird er als vertrauenswürdig angenommen?

Wer alle fünf Fragen mit Ja beantwortet, bringt die wichtigsten Voraussetzungen mit.

Fazit

Die zwölf Faktoren beschreiben, wie eine Anwendung gebaut sein muss, damit eine Plattform sie überhaupt betreiben kann. Die drei ergänzten Faktoren beschreiben, was zusätzlich nötig ist, damit sie in einem verteilten System beherrschbar bleibt: eine belastbare Schnittstelle, Beobachtbarkeit von innen heraus und Sicherheit als Grundannahme statt als Ausnahme. Das CNCF Cloud Native Maturity Model setzt beides in einen größeren Rahmen und zeigt, was mit dem Schritt in Produktion zum Standard wird.

Die Faktoren sind kein Zertifikat, das man erreicht, sondern eine Prüfliste, die bei jeder Architekturentscheidung hilft. Wer sie einhält, verlagert Komplexität aus der Anwendung in die Plattform, und damit auch Verantwortung.

kloudease übernimmt die Plattformseite dieser Verantwortung als vollständig gemanagte Cloud-native Umgebung: Kubernetes mit Observability, Secrets Management, Policy Enforcement und Backup & Recovery, auf jeder Cloud gleich und ohne Vendor Lock-in. Je näher deine Anwendung an den 15 Faktoren ist, desto mehr nimmt dir die Plattform ab. Und wenn du auch den Betrieb der Anwendung abgeben willst, ist SREaaS der nächste Schritt.