15 Factor App Deep Dive: Faktoren 1–6 (Grundlagen & Lifecycle)

TL;DR

• Die Faktoren 1–6 der 15-Factor App definieren den inneren Lebenszyklus einer Anwendung: von der Codebasis über Dependencies und Konfiguration bis hin zu Prozessen und Laufzeitverhalten.
• Eine einzige Codebasis mit klar deklarierten Dependencies und externer Konfiguration reduziert Betriebsrisiken, erleichtert Audits und schafft die Grundlage für belastbare, portable Deployments.
• Backing Services als austauschbare Ressourcen und strikt getrennte Build-/Release-/Run-Phasen sind zentrale Hebel für Resilienz, Portabilität und regulatorisch nachvollziehbare Änderungen.
• Stateless Prozesse unterstützen Hochverfügbarkeit und Disaster-Recovery – ein wichtiger Baustein für organisationsweite Compliance und Anforderungen an Resilience.
• Mit ohMyHelm als Paketierungswerkzeug der ayedo-Plattform lassen sich diese Faktoren systematisch in Helm-Charts und values.yaml-Dateien übersetzen – inklusive sauberer Trennung von Code, Konfiguration und Umgebung (ohne proprietäre Abhängigkeiten).

---

Warum die ersten sechs Faktoren den Unterschied machen

Die 15-Factor App erweitert die bekannten 12-Factor-Prinzipien um moderne Anforderungen wie Telemetrie und Security. In der Praxis entscheiden aber vor allem die Faktoren 1–6 darüber, ob eine Anwendung sich zuverlässig auf einer modernen Plattform betreiben lässt – und ob sie mittel- und langfristig mit Ihren Compliance- und Souveränitätszielen Schritt hält.

Diese ersten sechs Faktoren regeln:

• wie Sie Ihren Code strukturieren (Faktor 1),
• wie Sie Abhängigkeiten beherrschbar machen (Faktor 2),
• wie Sie Konfiguration behandeln (Faktor 3),
• wie Sie externe Systeme einbinden (Faktor 4),
• wie Sie den Delivery-Lifecycle organisieren (Faktor 5),
• und wie sich Ihre Prozesse zur Plattform verhalten (Faktor 6).

In Kombination legen sie fest, wie portabel, auditierbar und resilient Ihre Anwendungen sind – und damit auch, wie gut sie sich in ein europäisches Ökosystem mit klaren rechtlichen Rahmenbedingungen (etwa GDPR / DSGVO und nationale Aufsichtsvorgaben) einfügen.

ohMyHelm setzt genau hier an: als standardisiertes Paketierungswerkzeug, das diese Prinzipien in wiederverwendbare Helm-Charts und values.yaml-Dateien übersetzt. Schauen wir uns die einzelnen Faktoren an – mit Fokus auf praktische Auswirkungen und Compliance-Bezug.

---

Faktor 1: Codebase – eine Codebase, viele Deployments

Das Grundprinzip: Eine Anwendung hat genau eine Codebase, die in einem Versionskontrollsystem gepflegt wird. Aus dieser einen Codebase entstehen verschiedene Deployments: Entwicklung, Test, Staging, Produktion, eventuell Mandanten- oder Länder-Varianten.

Wesentliche Punkte:

• Kein Forking von Repositories pro Umgebung oder pro Kunde.
• Keine Kopien von Deployment-Manifesten mit leicht veränderten Parametern.
• Alle Umgebungen referenzieren dieselbe logische Codebasis, unterscheiden sich nur durch Konfiguration.

Für Verantwortungsträger hat das mehrere Vorteile:

• Nachvollziehbarkeit: Ein bestimmter Commit oder Tag ist eindeutig einer fachlichen Version zugeordnet – wichtig für Change-Management und Audits.
• Reduzierte Fehlerquellen: Keine divergierenden „Schatten-Repositories“ mit nicht dokumentierten Abweichungen.
• Schnellere Sicherheitsfixes: Patches werden einmal eingespielt, anschließend über alle relevanten Umgebungen ausgerollt.

Mit ohMyHelm erfolgt diese Trennung elegant: Sie definieren ein einziges Chart für Ihre Anwendung und verwenden unterschiedliche values.yaml-Dateien für Entwicklung, Test und Produktion. Der Anwendungs-Code bleibt derselbe, nur Parameter wie Ressourcenlimits, externe Endpoints oder Feature-Flags variieren. Für Compliance ist das ein Gewinn: Sie können jederzeit belegen, welches Chart mit welchen Werten zu welchem Zeitpunkt produktiv war.

---

Faktor 2: Dependencies – explizit deklarieren, nie auf System-Pakete verlassen

Faktor 2 fordert, dass alle Abhängigkeiten explizit deklariert und isoliert werden. Dazu zählen:

• Bibliotheken im Anwendungscode (z. B. via Maven, npm, pip),
• Betriebssystemnahe Pakete im Container-Image,
• Infrastrukturabhängigkeiten wie Datenbanken, Message Broker, Identity Provider.

Was Sie vermeiden wollen:

• „Es läuft bei mir, weil auf meinem Build-Host noch irgendein Systempaket installiert ist.“
• „In Cluster A ist das Basis-Image etwas anders als in Cluster B, deshalb verhält sich die Anwendung unterschiedlich.“

In einer containerisierten Umgebung heißt das:

• Container-Images sind vollständig selbstbeschreibend.
• Alle benötigten Bibliotheken und Tools sind im Image enthalten.
• Welche Version welcher Abhängigkeit verwendet wird, ist eindeutig dokumentiert.

Mit ohMyHelm wird dieses Prinzip strukturiert abgebildet:

• Das Helm-Chart deklariert seine eigenen Abhängigkeiten (z. B. Datenbank- oder Cache-Charts) mit klaren Versionsangaben.
• In der zentralen values.yaml-Datei werden die Container-Images samt Tags oder Digests hinterlegt – idealerweise ohne „latest“ in sensiblen Umgebungen.

Für Compliance ist das ein Schlüssel: Explizite Dependencies erleichtern Sicherheitsbewertungen, Software Bills of Materials (SBOMs) und ein strukturiertes Patch-Management. Wenn Sie etwa auf eine kritische Schwachstelle reagieren müssen, wissen Sie transparent, welche Komponenten betroffen sind und wo sie eingesetzt werden.

---

Faktor 3: Config – Konfiguration in der Umgebung, nicht im Code

Konfiguration ist alles, was sich zwischen Deployments ändert, ohne dass Sie den Code anfassen wollen: Datenbank-URLs, Feature-Flags, API-Keys, Mandanten-spezifische Endpoints, regionale Einstellungen.

Der Kern von Faktor 3:

• Konfiguration gehört nicht in die Codebase.
• Konfiguration wird aus der Umgebung geliefert – in Kubernetes typischerweise über Environment-Variablen, ConfigMaps und Secrets.
• Ein und dasselbe Container-Image kann so in unterschiedlichen Umgebungen mit unterschiedlichen Werten betrieben werden.

Mit ohMyHelm wird diese Trennung konkret:

• Funktionale Konfiguration (z. B. Feature-Flags, Logging-Level) wird in der values.yaml-Datei definiert und vom Chart in geeignete Kubernetes-Ressourcen übersetzt.
• Sensible Werte, etwa Datenbank-Passwörter oder OAuth-Client-Secrets, werden konsequent als Secrets behandelt und nicht in die Codebasis eingecheckt.
• Für jede Umgebung existiert eine eigene values-Datei, in der diese Konfigurationswerte gepflegt werden – inklusive klarer Verantwortlichkeiten, wer welche Werte ändern darf.

Der Bezug zur GDPR (DSGVO) ist direkt: Am 25.05.2018 trat die GDPR in Kraft und fordert u. a. eine datenschutzfreundliche Grundeinstellung („privacy by default“) und technische sowie organisatorische Maßnahmen zum Schutz personenbezogener Daten. Wenn Zugriffspunkte zu Datenbanken, Identitätsanbietern oder Speichersystemen hart im Code verankert sind, wird:

• die Trennung von Rollen (Entwicklung vs. Betrieb) erschwert,
• das Rotieren von Secrets und Schlüsseln unnötig komplex,
• das Risiko erhöht, dass sensible Informationen versehentlich in Repositories oder Artefakten landen.

Durch konsequente Externalisierung der Konfiguration in values.yaml und Secrets bekommen Sie:

• klare Schnittstellen, an denen Security- und Compliance-Teams ansetzen können,
• definierte Stellen, an denen Zugänge zu personenbezogenen Daten geregelt und geprüft werden,
• die Möglichkeit, Konfiguration pro Mandant oder Region anzupassen, ohne die Anwendung selbst zu verändern.

Ein praktisches Beispiel ist Identity & Access Management: Setzen Sie etwa auf einen souveränen Identity Provider wie Keycloak, dann verweisen Ihre Anwendungen lediglich per Konfiguration auf den jeweiligen Keycloak-Endpunkt, die Realm- und Client-Konfiguration. Die Anwendung selbst bleibt generisch; regulatorisch relevante Details liegen in der Umgebung.

---

Faktor 4: Backing Services – austauschbare Ressourcen

Backing Services sind alle externen Systeme, die Ihre Anwendung nutzt: Datenbanken, Message Queues, Caches, S3-kompatible Storages, E-Mail-Provider, aber auch Dienste wie Keycloak für Authentifizierung.

Die zentrale Idee:

• Backing Services werden als angehängte Ressourcen behandelt, nicht als fest verdrahteter Bestandteil der Anwendung.
• Die Anwendung spricht diese Services über wohl definierte Schnittstellen an, typischerweise in Form von URLs, Hostnamen und Ports, die über Konfiguration bereitgestellt werden.
• Ein Wechsel des Backing Service (z. B. von einem Datenbank-Cluster zu einem anderen oder von einem externen zu einem souveränen europäischen Anbieter) erfolgt durch Konfigurationsänderung, nicht durch Codeänderung.

Mit ohMyHelm spiegeln sich diese Prinzipien in den values.yaml-Dateien wider:

• Für jede Umgebung definieren Sie die Endpoints ihrer Backing Services – etwa unterschiedliche Datenbank-Cluster für Test und Produktion oder verschiedene Object-Storage-Instanzen in unterschiedlichen Regionen.
• Das Chart sorgt dafür, dass diese Informationen in der Laufzeitumgebung der Anwendung sauber ankommen, ohne dass die Anwendung selbst angepasst werden muss.

Für Compliance und Datensouveränität ist das ein strategischer Vorteil:

• Sie können Anwendungen vergleichsweise einfach in eine andere Region oder zu einem anderen Provider migrieren, wenn regulatorische Anforderungen sich ändern.
• Sie sind weniger stark an einzelne Infrastrukturbetreiber gebunden – ein wichtiges Ziel für einen starken, unabhängigen Technologiestandort Europa.
• Sie können sensible Backing Services (z. B. Datenbanken mit personenbezogenen Daten) strikt in EU-Rechenzentren betreiben, während weniger kritische Services flexibler gewählt werden.

---

Faktor 5: Build, Release, Run – strikte Trennung im Lifecycle

Faktor 5 fordert eine klare Trennung der Phasen:

• Build: Aus dem Quellcode werden unveränderliche Artefakte gebaut, typischerweise Container-Images.
• Release: Ein Release kombiniert ein bestimmtes Build-Artefakt mit einer bestimmten Konfiguration. Daraus entsteht eine exakt definierte Version, die deployt werden kann.
• Run: In dieser Phase werden Releases in den Zielumgebungen ausgeführt – ohne die Artefakte oder die zugehörige Konfiguration zu verändern.

In vielen Organisationen verschwimmen diese Grenzen: Images werden direkt in der Produktion neu gebaut, Konfiguration wird „schnell im Cluster angepasst“, Releases werden nicht sauber versioniert. Das erschwert:

• Root-Cause-Analysen („Welche Version lief genau?“),
• Sicherheitsbewertungen und Freigaben,
• Nachweise gegenüber Auditoren.

Mit ohMyHelm lässt sich eine saubere Trennung sehr strukturiert implementieren:

• Im Build-Schritt entsteht ein Container-Image einer Anwendungsversion.
• Im Release-Schritt wird ein Helm-Chart mit genau diesem Image und einem Satz geprüfter values.yaml-Dateien kombiniert. Dieses Bündel ist Ihr Release.
• In der Run-Phase werden Releases mit klaren Versionsangaben in die entsprechenden Kubernetes-Cluster ausgerollt. Änderungen an Konfiguration oder Images erzeugen neue Releases; es gibt keinen „stillen Drift“.

Für Compliance ist diese Transparenz Gold wert: Sie können jederzeit nachvollziehen,

• welche Kombination aus Code und Konfiguration in welcher Umgebung aktiv war,
• wann ein bestimmter Fix oder ein sicherheitsrelevantes Update ausgerollt wurde,
• und ob die in Policies definierten Freigabeprozesse eingehalten wurden.

---

Faktor 6: Processes – stateless, share-nothing

Faktor 6 betrachtet die Anwendung als eine Menge von Prozessen, die:

• horizontal skalierbar sind,
• unabhängig voneinander gestartet und gestoppt werden können,
• kein lokales, nicht repliziertes State halten („stateless“),
• keine Schreibzugriffe auf lokale Filesysteme benötigen, die für den korrekten Betrieb kritisch wären.

Zustand – ob Sessions, Business-Daten oder lange laufende Workflows – gehört in Backing Services: Datenbanken, Caches, Object Storages, Messaging-Systeme. Die Prozesse selbst bleiben austauschbar und kurzlebig.

Praktische Konsequenzen:

• Ein einzelner Prozess darf jederzeit ausfallen, ohne dass Daten verloren gehen.
• Skalierung bedeutet, weitere Prozesse derselben Art hinzuzufügen, nicht, einen einzelnen „dicken“ Prozess zu vergrößern.
• Rolling Updates und Blue-Green-Deployments werden deutlich unkomplizierter.

ohMyHelm unterstützt dieses Muster, indem es:

• standardmäßig Deployments erzeugt, die stateless konzipiert sind,
• zustandsbehaftete Komponenten (z. B. Datenbanken) nur dann als StatefulSets mit persistentem Storage behandelt, wenn dies bewusst und explizit konfiguriert wird,
• Session-Daten und andere kurzlebige Zustände klar in Caches oder spezialisierte Backing Services auslagert, wie in der values.yaml-Datei definiert.

Aus Resilience- und Compliance-Sicht ist das zentral: Viele Regulierungen fordern nachvollziehbare Konzepte für Hochverfügbarkeit, Wiederanlauf und Datenintegrität. Stateless Prozesse

• erleichtern das Erreichen von Verfügbarkeitszielen,
• reduzieren das Risiko von Datenverlusten bei Knoten- oder Zonen-Ausfällen,
• unterstützen robuste Disaster-Recovery-Szenarien, da Prozesse jederzeit neu aufgebaut werden können, solange die dahinterliegenden Backing Services verfügbar sind.

---

Praktische Arbeit mit ohMyHelm und values.yaml

Die gemeinsamen Muster der Faktoren 1–6 lassen sich sehr gut über eine saubere Strukturierung Ihrer values.yaml-Dateien abbilden:

• Eine zentrale Codebasis und ein zentrales Chart pro Anwendung (Faktor 1).
• Explizite Deklaration aller Images und Sub-Charts mit Versionsangaben (Faktor 2).
• Strikte Trennung von Code und Konfiguration in eigenen values-Dateien pro Umgebung (Faktor 3).
• Klare Definition aller Backing-Service-Endpunkte und Zugangsdaten über Konfiguration, nicht über Code (Faktor 4).
• Versionierte Kombinationen aus Chart, Image und values-Datei als Releases (Faktor 5).
• Standardmäßig stateless Deployments, State nur in bewusst definierten Ressourcen (Faktor 6).

Für technische Führungskräfte entsteht damit ein Rahmen, der zwei Ziele gleichzeitig adressiert:

1. Cloud-native Best Practices werden in wiederholbare, teamübergreifende Standards übersetzt.
2. Compliance-Anforderungen lassen sich technisch konkret verankern, statt nur in Richtlinienpapieren zu existieren.

---

Häufige Fragen

Wie strikt muss ich die 15 Faktoren einhalten, um „compliant“ zu sein?

Die 15-Factor-Prinzipien sind kein Gesetzestext und keine direkte Norm. Dennoch unterstützen sie sehr konkret die Einhaltung rechtlicher Vorgaben wie der GDPR oder interner Compliance-Richtlinien.

In der Praxis geht es weniger darum, „100 % 15-Factor-konform“ zu sein, sondern darum, bewusste Design-Entscheidungen zu treffen:

• Wenn Sie Konfiguration sauber externalisieren, fällt es leichter, Berechtigungen zu trennen und Secrets sicher zu verwalten.
• Wenn Sie Dependencies explizit deklarieren, wird Ihr Schwachstellenmanagement nachvollziehbar.
• Wenn Sie stateless Prozesse etablieren, verbessert sich Ihre Resilience-Story gegenüber Aufsichtsbehörden und Kunden.

Sie können also schrittweise vorgehen und Faktoren priorisieren, die den größten Hebel für Sicherheit, Stabilität und Nachvollziehbarkeit haben. Wichtig ist die Richtung, nicht dogmatische Perfektion.

Was ist ein sinnvoller Einstieg, wenn meine bestehende App mehrere Faktoren verletzt?

Die meisten gewachsenen Anwendungen verstoßen gegen mehrere der 15 Faktoren – das ist normal. Empfehlenswert ist ein inkrementeller Ansatz, oft in dieser Reihenfolge:

1. Config entkoppeln (Faktor 3): Bringen Sie sensible und umgebungsspezifische Konfiguration aus dem Code in die Umgebung. Das ist organisatorisch und technisch meist gut handhabbar und wirkt sich direkt auf Sicherheit und Wartbarkeit aus.
2. Dependencies inventarisieren (Faktor 2): Erfassen Sie, welche Bibliotheken, Images und externen Services tatsächlich im Einsatz sind. Das bildet die Grundlage für eine saubere Paketierung.
3. Build-/Release-Prozess klären (Faktor 5): Etablieren Sie klar erkennbare Releases, die Sie in Test- und Produktionsumgebungen gleichermaßen verwenden können.
4. Schrittweise stateless (Faktor 6): Identifizieren Sie Stellen, an denen noch lokaler State gehalten wird, und planen Sie dessen Migration in Backing Services.

ohMyHelm kann hier als strukturierender Rahmen dienen: Indem Sie die Anwendung als Helm-Chart modellieren und Konfiguration konsequent in values.yaml-Dateien auslagern, erzwingen Sie gewissermaßen die Auseinandersetzung mit diesen Faktoren – ohne die Anwendung komplett neu schreiben zu müssen.

Welche Rolle spielt ayedo/ohMyHelm in einem regulierten Umfeld konkret?

ayedo positioniert sich bewusst an der Schnittstelle zwischen moderner Cloud-Native-Technik und den wachsenden Anforderungen an Souveränität und Compliance in Europa. ohMyHelm ist dabei das Werkzeug, mit dem Sie:

• Anwendungen factor-orientiert paketieren,
• Konfiguration und Secrets robust strukturieren,
• Backing Services sauber als austauschbare Ressourcen modellieren,
• und reproduzierbare Releases erstellen, die sich gut auditieren lassen.

In Kombination mit weiteren Bausteinen der ayedo-Plattform – etwa Identity-Lösungen wie Keycloak oder einer standardisierten Kubernetes-Plattform – entsteht ein souveränes Ökosystem, das technische Best Practices und regulatorische Anforderungen zusammenführt, statt sie gegeneinander auszuspielen.

Weitere Fragen? Siehe unsere FAQ

---

Von der Theorie zur Umsetzung

Die ersten sechs Faktoren der 15-Factor App sind mehr als Architekturempfehlungen – sie sind ein praktischer Rahmen, um moderne Anwendungen sowohl technisch als auch organisatorisch verantwortbar zu betreiben. Gerade in Europa, wo mit der GDPR seit dem 25.05.2018 und zusätzlichen sektoralen Vorgaben klare Anforderungen an Datenschutz, Resilience und Nachvollziehbarkeit gelten, zahlen diese Prinzipien direkt auf Ihre Handlungsfähigkeit ein.

ayedo verfolgt den Ansatz, diese Prinzipien nicht abstrakt zu diskutieren, sondern sie in konkrete Werkzeuge und Prozesse zu übersetzen. Mit ohMyHelm erhalten Sie ein Paketierungsmodell, das:

• eine einzige Codebasis in klar definierten Helm-Charts abbildet,
• Dependencies explizit und versioniert beschreibt,
• Konfiguration über values.yaml-Dateien in die Umgebung verlagert,
• Backing Services als austauschbare Ressourcen behandelt,
• den Build-/Release-/Run-Lifecycle klar strukturiert,
• und stateless Prozesse als Standard etabliert, wo immer das sinnvoll ist.

So können Teams sich auf fachliche Innovation konzentrieren, während die Plattformseite – inklusive Compliance-Aspekten – durch wiederholbare, überprüfbare Muster abgesichert ist. Wenn Sie diese Prinzipien in Ihrer Organisation verankern möchten und dabei nicht bei null anfangen wollen, ist ohMyHelm ein pragmatischer Einstiegspunkt.

Der einfachste Weg, das in der Praxis auszuprobieren, ist ein schlanker Einstieg mit einem konkreten Service oder einer Pilotanwendung. Genau dafür haben wir den ohMyHelm Quick Start vorbereitet.