Cloud-Native-Ansätze — 12-Factor App und was das in der Praxis bedeutet

„Cloud-native” hat sich im letzten Jahr von Konferenzen in reale Projektanforderungen bewegt. Was bedeutet es wirklich? Für uns ist es eine Reihe von Prinzipien, die eine Anwendung betreibbar, skalierbar und resilient machen. Die 12-Factor App ist ein guter Ausgangspunkt.

12-Factor App — was wirklich Sinn ergibt¶

III. Config in Umgebungsvariablen. Keine Konfigurationsdateien in Git. Auf Kubernetes: ConfigMaps und Secrets.

VI. Zustandslose Prozesse. Sessions in Redis, Dateien im Object Storage, gemeinsamer Cache. 10 Replikas, der Load Balancer verteilt sie beliebig.

XI. Logs als Event Streams. Die Anwendung loggt auf stdout. Die Infrastruktur (Fluentd) sammelt und sendet an Elasticsearch.

Health Checks — Readiness vs. Liveness¶

Liveness: „Lebt sie?” — Kubernetes startet sie neu. Readiness: „Nimmt sie Traffic an?” — wird vom Load Balancer entfernt. Ein schlechter Liveness-Timeout → Restart-Schleife unter Last. Spring Boot Actuator löst das elegant.

Graceful Shutdown¶

SIGTERM → keine neuen Requests mehr annehmen → laufende Arbeit abschließen → beenden. Pre-Stop-Hook (sleep 5) gibt dem Load Balancer Zeit, den Pod zu entfernen. Achtung bei Batch-Jobs (Checkpoint/Resume), DB-Pools (Drain), Message Consumern.

Observability — drei Säulen¶

• Metriken (Prometheus): RED-Methode — Request Rate, Error Rate, Duration
• Logs (ELK/Loki): strukturiertes JSON mit Correlation ID
• Tracing (Jaeger): verteiltes Tracing über Services hinweg — Game Changer

Immutable Infrastructure¶

Kein SSH auf Produktion. Keine Quick Fixes an einem Pod. Änderung = neue Version über CI/CD. Ein Pod ist Vieh, kein Haustier. Mehr eine kulturelle als eine technische Veränderung.

Cloud-native ist ein Mindset¶

Es bedeutet nicht nur „läuft in der Cloud”. Es ist zustandslos, observable, resilient, automatisiert. Man kann auch On-Premise mit Kubernetes cloud-native sein. Und in der Cloud nicht cloud-native (Lift-and-Shift-VM).