Cloud-Native

Was ist Cloud-Native?

Cloud-Native ist ein Architektur- und Entwicklungsansatz, bei dem Anwendungen von Grund auf für die Cloud konzipiert werden. Statt bestehende Anwendungen einfach in die Cloud zu verschieben (Lift-and-Shift), werden Cloud-Native-Anwendungen so gebaut, dass sie die Elastizität, Skalierbarkeit und Managed Services der Cloud vollständig ausnutzen.

Die Cloud Native Computing Foundation (CNCF) definiert Cloud-Native als Ansatz, der Container, Service Meshes, Microservices, unveränderliche Infrastruktur und deklarative APIs nutzt. Für mittelständische Unternehmen bedeutet das: Anwendungen, die sich automatisch an wechselnde Last anpassen, schneller weiterentwickelt werden können und weniger Betriebsaufwand erfordern.

Cloud-Native vs. Cloud-Ready

Diese beiden Begriffe werden oft verwechselt, unterscheiden sich aber grundlegend:

• Cloud-Ready: Eine bestehende Anwendung, die in der Cloud laufen kann, aber nicht für die Cloud optimiert ist. Typisches Beispiel: Eine monolithische Java-Anwendung auf einer EC2-Instanz. Sie läuft in der Cloud, nutzt aber keine Cloud-spezifischen Vorteile.
• Cloud-Native: Eine Anwendung, die für die Cloud architektonisch gestaltet ist. Sie nutzt Container, skaliert horizontal, verwendet Managed Services und ist über CI/CD automatisiert deployed. Sie wäre on-premises nur schwer zu betreiben.

Die CNCF und ihr Ökosystem

Die Cloud Native Computing Foundation (CNCF) ist die Organisation hinter Kubernetes und hunderten weiterer Cloud-Native-Projekte. Die CNCF Landscape umfasst über 1.000 Projekte in Kategorien wie Container Runtime, Orchestrierung, Service Mesh, Observability, Messaging und Storage. Für mittelständische Unternehmen ist die CNCF Landscape eine Orientierungshilfe bei der Auswahl von Tools.

Die 12-Factor App Methodik

Die 12-Factor App ist ein Regelwerk für die Entwicklung moderner, cloud-nativer Anwendungen. Die wichtigsten Faktoren sind:

• Codebase: Eine Codebase, viele Deployments. Jede Umgebung (Dev, Staging, Prod) nutzt denselben Code.
• Dependencies: Alle Abhängigkeiten explizit deklarieren. Keine Annahmen über installierte Systemtools.
• Config: Konfiguration über Umgebungsvariablen. Niemals Credentials oder Konfiguration im Code.
• Backing Services: Datenbanken, Message Queues und Caches als austauschbare, angehängte Ressourcen behandeln.
• Build, Release, Run: Strikte Trennung zwischen Build (kompilieren), Release (Build + Config) und Run (Prozess starten).
• Processes: Anwendungen als zustandslose Prozesse ausführen. Session-Daten gehören in Backing Services.
• Port Binding: Die Anwendung exponiert sich selbst über Port Binding, nicht über externe Webserver.
• Concurrency: Skalierung über Prozesse (horizontal), nicht über Threads (vertikal).
• Disposability: Prozesse können jederzeit gestartet und gestoppt werden. Schnelle Startzeiten, graceful Shutdown.
• Dev/Prod Parity: Minimaler Unterschied zwischen Entwicklungs- und Produktionsumgebung.
• Logs: Logs als Event-Streams behandeln. Die Anwendung kümmert sich nicht um Routing oder Storage von Logs.
• Admin Processes: Einmalige Verwaltungsaufgaben als separate Prozesse ausführen.

Microservices als Cloud-Native-Architektur

Microservices sind ein zentrales Element der Cloud-Native-Architektur. Statt einer monolithischen Anwendung werden einzelne Geschäftsfunktionen als unabhängige Services entwickelt, deployed und skaliert. Jeder Microservice hat seine eigene Datenbank, sein eigenes Deployment und sein eigenes Team.

Wann lohnen sich Microservices für den Mittelstand?

Microservices sind kein Allheilmittel. Für viele mittelständische Unternehmen ist ein „Modular Monolith" der bessere Start: eine monolithische Anwendung mit klar definierten Modulen, die bei Bedarf einzeln in Microservices extrahiert werden können. Microservices lohnen sich, wenn:

• Verschiedene Teile der Anwendung unterschiedlich skalieren müssen.
• Mehrere Teams unabhängig voneinander entwickeln und deployen wollen.
• Einzelne Komponenten in unterschiedlichen Technologien (Sprachen, Frameworks) entwickelt werden sollen.

Container als Grundlage

Container – insbesondere Docker – sind die Basis jeder Cloud-Native-Architektur. Sie packen eine Anwendung mit allen Abhängigkeiten in ein portables Image, das überall gleich läuft: auf dem Laptop des Entwicklers, im CI/CD-System und in Produktion. Kubernetes orchestriert diese Container in Produktion.

Für den Mittelstand ist der Einstieg in Container oft der erste Schritt Richtung Cloud-Native: Bestehende Anwendungen werden containerisiert, in einer Container Registry gespeichert und über eine CI/CD-Pipeline deployed. Darauf aufbauend können schrittweise weitere Cloud-Native-Praktiken eingeführt werden.