Cloud-Native Architektur — Praktischer Leitfaden für Cloud Native Beratung

Cloud-Native heißt nicht „Wir nutzen Kubernetes“

Der Begriff taucht in jedem Vendor-Pitch auf. Wer Cloud Native Beratung sucht, muss verstehen, was dahintersteckt. Aber Container auf einem Managed Cluster laufen zu lassen, macht die Architektur nicht cloud-native. Cloud-native bedeutet, dass das System die Elastizität, Automatisierung und Resilienz der Cloud-Plattform aktiv ausnutzt. Wenn die App nach einem fehlgeschlagenen Deploy immer noch eine SSH-Session um 3 Uhr morgens braucht, ist sie bestenfalls cloud-gehostet.

Die Cloud Native Computing Foundation (CNCF) definiert Cloud-Native-Technologien als solche, die „Organisationen befähigen, skalierbare Anwendungen in modernen, dynamischen Umgebungen wie Public, Private und Hybrid Clouds zu erstellen und zu betreiben.“ Diese Definition ist bewusst breit gefasst. Die praktische Frage lautet: Was braucht es konkret?

Die Twelve-Factor-Grundlage hält Stand

Die Twelve-Factor App Methodik wurde 2011 von Heroku-Ingenieuren veröffentlicht. Fünfzehn Jahre später bleibt sie die beste Einstiegs-Checkliste für Cloud-Native-Design. Die Faktoren, an denen die meisten Teams scheitern:

Konfiguration in der Umgebung, nicht im Code. Wer im Repo nach localhost:5432 oder hartcodierten API-Keys greppen kann, hat ein Config-Problem. Umgebungsvariablen, Kubernetes ConfigMaps oder externe Secret-Stores (wie HashiCorp Vault oder Cloud-native Alternativen) halten die Konfiguration portabel über alle Umgebungen hinweg.

Zustandslose Prozesse. Jede Instanz des Services muss disposable sein. Session-State gehört in Redis oder eine Datenbank, nicht in den lokalen Speicher. Stirbt der Prozess, trifft der nächste Request eine andere Instanz ohne Datenverlust. Genau das macht horizontale Skalierung möglich.

Port-Binding. Die App exportiert HTTP (oder gRPC) als Service durch Bindung an einen Port. Kein Tomcat, kein IIS — nur ein eigenständiger Prozess, an den ein Container-Orchestrator Traffic routen kann.

Disposability. Schneller Start, sauberes Herunterfahren. Kubernetes sendet SIGTERM und erwartet, dass der Pod innerhalb von terminationGracePeriodSeconds aufräumt. Wenn der Java-Service 90 Sekunden zum Booten braucht, hat man einen Skalierungsengpass, den keine Infrastruktur löst.

Service Mesh: Wann es Sinn macht (und wann nicht)

Ein Service Mesh wie Istio oder Linkerd fügt jedem Pod einen Sidecar-Proxy hinzu, der mTLS, Retries, Circuit Breaking und Traffic Shifting übernimmt. Es ist mächtig. Es ist auch komplex.

Ein Mesh braucht man vermutlich, wenn:

• 20+ Services vorhanden sind und konsistentes mTLS ohne Änderungen am Anwendungscode nötig ist
• Canary Deployments mit Traffic Splitting gewünscht sind (5% auf die neue Version)
• Fein-granulare Observability gebraucht wird (Latenz-Percentile pro Service-Paar)

Ein Mesh braucht man vermutlich nicht, wenn:

• Weniger als 10 Services laufen
• Kubernetes NetworkPolicies und Application-Level TLS die Sicherheitsanforderungen abdecken
• Das Team bereits ausgelastet ist — ein Mesh bringt operativen Overhead mit

Linkerd ist schlanker als Istio und lässt sich inkrementell einführen. Der Linkerd Getting-Started Guide bringt es in unter 15 Minuten zum Laufen. Dort starten, wenn man evaluieren möchte, ohne sich auf Istios vollständige Control Plane festzulegen.

Observability ist keine Option

Man kann nicht betreiben, was man nicht sehen kann. Cloud-native Systeme sind per Definition verteilt, und verteilte Systeme fallen auf verteilte Art und Weise aus. Die drei Säulen:

Metriken. Prometheus ist der De-facto-Standard. /metrics von jedem Service exponieren, mit Prometheus scrapen, mit Grafana visualisieren. Die RED-Methode — Rate, Errors, Duration — liefert das essentielle Dashboard für jeden Service.

Logs. Strukturierte JSON-Logs, zentral gesammelt. Loki ist kosteneffizient, wenn man bereits im Grafana-Ökosystem unterwegs ist. Die Kerndisziplin: Correlation IDs in jeder Log-Zeile, damit sich ein Request über Services hinweg nachverfolgen lässt.

Traces. OpenTelemetry ist der Industriestandard für Distributed Tracing. Services einmalig instrumentieren, zu Jaeger, Tempo oder einem kompatiblen Backend exportieren. Wenn ein User meldet „die Seite ist langsam“, zeigen Traces exakt, welcher Service-Call 800ms hinzugefügt hat.

Kostenkontrolle: Die Cloud-Native-Steuer

Cloud-native falsch gemacht ist teuer. Auto-Scaling ohne Limits, über-provisionierte Nodes und vergessene Dev-Cluster summieren sich schnell.

Requests und Limits richtig dimensionieren. Kubernetes Resource Requests bestimmen das Scheduling; Limits bestimmen OOM Kills. Der Vertical Pod Autoscaler (VPA) kann Werte basierend auf tatsächlicher Nutzung empfehlen. Zuerst im Recommendation-Mode laufen lassen.

Spot/Preemptible Instances für unkritische Workloads nutzen. CI-Runner, Batch-Jobs und Dev-Umgebungen verkraften Unterbrechungen. Cloud-Anbieter bieten 60–90% Rabatt auf Preemptible-Kapazität.

Budgets und Alerts setzen. Jeder Cloud-Anbieter bietet Budget-Alerts an. Nutzen. Die teuerste Cloud-Rechnung ist immer die, die bis Monatsende niemand bemerkt hat.

Abschalten, was nicht gebraucht wird. Dev- und Staging-Cluster außerhalb der Geschäftszeiten auf Null skalieren. Tools wie Karpenter für AWS oder Cluster-Autoscaler Node-Pool-Scheduling helfen bei der Automatisierung.

Migrationsstrategie: Nicht Rewrite, sondern Strangler

Der größte Fehler, den Teams machen, ist eine „Big Bang“-Migration zu Cloud-Native zu planen. Stattdessen das Strangler-Fig-Pattern nutzen: Neuen Traffic über ein Cloud-Native-Gateway routen, inkrementell Bounded Contexts aus dem Monolithen in Services extrahieren und Legacy-Komponenten einzeln abschalten.

Eine praktische Reihenfolge:

1. Den Monolithen zuerst containerisieren. In Kubernetes zum Laufen bringen ohne Refactoring. Das gibt die Deployment-Pipeline und Infrastruktur-Vertrautheit.
2. Die Domain mit der höchsten Änderungsrate extrahieren. Der Teil der Codebasis, der sich am häufigsten ändert, profitiert am meisten von unabhängigem Deployment.
3. Observability hinzufügen, bevor weiter aufgeteilt wird. Man braucht Sichtbarkeit in die Inter-Service-Kommunikation, bevor man mehr davon erzeugt.
4. Alles automatisieren. GitOps mit ArgoCD oder Flux stellt sicher, dass der Cluster-State dem Git-Repo entspricht. Kein manuelles kubectl apply in Produktion.

Was „Production-Ready“ wirklich bedeutet

Ein Cloud-Native-Service ist produktionsreif, wenn er hat:

• Health Checks. Liveness- und Readiness-Probes, die Kubernetes nutzt, um hängende Pods neuzustarten und unhealthy Pods aus dem Load Balancing zu entfernen.
• Graceful Shutdown. SIGTERM behandeln, laufende Requests abarbeiten, Datenbankverbindungen schließen.
• Circuit Breaker. Wenn ein Downstream-Service ausfällt, sofort fehlschlagen statt Requests aufzustauen, bis auch der eigene Service umfällt.
• Rate Limiting. Den Service vor Traffic-Spikes schützen — ob durch legitime Last oder fehlerhafte Clients.
• Runbooks. Wenn der Pager um 2 Uhr morgens losgeht, braucht der On-Call-Engineer einen dokumentierten Lösungsweg, kein Stammwissen.

Das Fazit

Cloud-native ist eine Architektur-Disziplin, kein Produkt zum Kaufen. Mit den Twelve-Factor-Prinzipien starten, Observability früh einbauen, Kubernetes-Primitives nutzen bevor man nach Service Meshes greift, und inkrementell migrieren. Das Ziel ist nicht, jedes CNCF-Projekt einzusetzen — sondern Systeme zu bauen, die skalieren, sich selbst heilen und ohne Drama deployen.