15-Factor App
Prinzipien für Cloud-Native Anwendungen

Die ursprünglichen 12-Factor App Prinzipien von Heroku waren wegweisend für Cloud-Native Entwicklung. Mit der Evolution von Cloud-Infrastruktur, Microservices und Sicherheitsanforderungen wurden drei weitere essenzielle Faktoren hinzugefügt: API First, Telemetry und Authentication & Authorization.

Die ersten drei Faktoren bilden das Fundament für reproduzierbare und wartbare Cloud-Anwendungen. Sie definieren, wie Code verwaltet, Abhängigkeiten deklariert und Konfiguration von Code getrennt wird.

1. Codebase

Eine Codebase, viele Deployments. Jede Anwendung wird in einem einzelnen Versionskontrollsystem verwaltet. Verschiedene Versionen werden in unterschiedlichen Umgebungen deployed – Dev, Staging, Production – aber alle stammen aus derselben Codebase.

2. Dependencies

Explizit deklarieren und isolieren. Alle Abhängigkeiten müssen explizit deklariert werden (z.B. via requirements.txt, package.json, go.mod). Die Anwendung darf sich niemals auf system-weite Pakete verlassen.

3. Config

Konfiguration in der Umgebung speichern. Alles, was zwischen Deployments variiert (Credentials, URLs, Feature Flags) gehört in Umgebungsvariablen – nie in den Code. Dies ermöglicht sichere und flexible Deployments.

Diese Faktoren definieren, wie Anwendungen mit externen Services interagieren und wie der Lifecycle von Build bis Runtime organisiert wird. Sie fördern lose Kopplung und klare Trennung der Deployment-Phasen.

4. Backing Services

Services als angehängte Ressourcen behandeln. Datenbanken, Message Queues, SMTP-Server und andere Backing Services werden als austauschbare Ressourcen behandelt. Ein Wechsel sollte nur eine Config-Änderung erfordern, keinen Code-Change.

5. Build, Release, Run

Strikte Trennung der Build- und Run-Stages. Build erstellt ein Deployment-Artefakt aus Code, Release kombiniert Build mit Config, Run führt die Anwendung aus. Diese Stages dürfen sich niemals vermischen.

6. Processes

Anwendung als stateless Processes ausführen. Prozesse sollten zustandslos und share-nothing sein. Persistenter State gehört in Backing Services wie Datenbanken oder Object Storage, nie in den Prozess-Speicher.

Die Faktoren für moderne Netzwerk-Architektur und horizontale Skalierung. Sie beschreiben, wie Services exponiert werden, wie Skalierung funktioniert und warum schnelle Startzeiten kritisch sind.

7. Port Binding

Services via Port Binding exportieren. Die Anwendung ist vollständig self-contained und exponiert Services über Port Binding (z.B. HTTP auf Port 8080). Sie ist nicht abhängig von einem externen Webserver wie Apache oder nginx.

8. Concurrency

Horizontal skalieren via Process Model. Skalierung erfolgt horizontal durch Starten weiterer Prozesse, nicht vertikal durch größere Maschinen. Unterschiedliche Workload-Typen (Web, Worker, Cron) werden als separate Prozess-Typen behandelt.

9. Disposability

Robustheit durch schnelle Starts und graceful Shutdown. Prozesse sollten in Sekunden starten und bei SIGTERM sauber herunterfahren können. Dies ermöglicht schnelles Skalieren, robuste Deployments und Fehlertoleranz.

Diese Faktoren adressieren den täglichen Betrieb: Wie bleibt Dev/Prod synchron? Wie werden Logs behandelt? Und wie führt man administrative Tasks aus, ohne die 12-Factor-Prinzipien zu verletzen?

10. Dev/Prod Parity

Dev, Staging und Production so ähnlich wie möglich halten. Zeitliche, personelle und technische Unterschiede zwischen Umgebungen minimieren. Entwickler sollten ihre eigenen Deployments durchführen können, und alle Umgebungen sollten dieselben Backing Services nutzen.

11. Logs

Logs als Event Streams behandeln. Die Anwendung schreibt Logs nach stdout/stderr und kümmert sich nicht um Routing oder Storage. Das ermöglicht flexible Log-Aggregation und -Analyse durch externe Tools wie VictoriaLogs .

12. Admin Processes

Admin-Tasks als One-Off Processes ausführen. Database Migrations, einmalige Scripts oder REPL-Sessions werden in derselben Umgebung ausgeführt wie reguläre Anwendungs-Prozesse – mit derselben Codebase und Config.

Die drei neuen Faktoren reflektieren die Evolution moderner Cloud-Architekturen: API-First Design für Interoperabilität, Telemetry für Observability und Authentication & Authorization für Zero-Trust Security.

13. API First

APIs zuerst designen, dann implementieren. Definieren Sie API-Contracts mit OpenAPI/Swagger, bevor Sie Code schreiben. Dies ermöglicht parallele Entwicklung, frühe Stakeholder-Abstimmung, automatische Dokumentation und Mock-Services – und reduziert Abhängigkeiten zwischen Teams erheblich.

14. Telemetry

Observability durch Metriken, Traces und Events. Logs allein reichen nicht – moderne Anwendungen benötigen strukturierte Metriken, Distributed Tracing und Real-User Monitoring. Telemetrie ermöglicht proaktives Monitoring, schnelleres Debugging und datenbasierte Entscheidungen in komplexen Microservice-Umgebungen.

15. Authentication & Authorization

Security von Anfang an, in jedem Layer. Alle API-Endpunkte müssen authentifiziert und autorisiert werden. Nutzen Sie moderne Standards wie OAuth2 , OpenID Connect und JWT . Implementieren Sie Role-Based Access Control (RBAC) und servieren Sie ausschließlich über HTTPS.

Die ursprünglichen 12 Faktoren wurden 2011 definiert – eine Ära vor Microservices-Dominanz, Container-Orchestrierung und Zero-Trust Security. Die drei neuen Faktoren sind nicht optional, sondern essentiell für moderne Cloud-Native Anwendungen:

Wir betreiben Managed Kubernetes und die Plattform-Services für 15-Factor Anwendungen – TLS, Observability , Identity , Delivery und Backing Services. Sie entwickeln am Produkt, ayedo übernimmt den Operations-Lifecycle.