Cloud Native

Was bedeutet Cloud Native?

Cloud Native bezeichnet einen Architekturansatz, bei dem eine Anwendung von vornherein für den Betrieb in einer Cloud entworfen wird. Statt eines geschlossenen Gesamtprogramms entstehen viele kleine, voneinander unabhängige Dienste, die in Containern laufen und über Schnittstellen zusammenarbeiten. Eine zentrale Steuerung startet, verteilt und ersetzt diese Dienste im laufenden Betrieb automatisch.

Der Ansatz ist unabhängig davon, ob eine Public, Private oder Hybrid Cloud genutzt wird. Getragen wird er von der 2015 gegründeten Cloud Native Computing Foundation, einem Projekt der Linux Foundation, unter deren Dach auch Kubernetes als verbreiteter Standard für die Steuerung von Containern entstand. Die Verbindung zu bestehenden ERP- oder Fachsystemen übernimmt eine Cloud-Native-Middleware, weil die einzelnen Dienste sonst jede Anbindung selbst mitbringen müssten.

Microservices und Container

Eine solche Anwendung zerlegt ihre Aufgaben in einzelne Dienste. Ein Onlineshop trennt dann etwa Kundendaten, Bestellung, Versand und Bezahlung voneinander, statt sie in einem Programm zu bündeln. Jeder Dienst wird eigenständig entwickelt und ausgetauscht, die Verständigung läuft meist über REST-Schnittstellen, die den inneren Aufbau des Gegenübers verbergen.

Verpackt werden diese Dienste in Container, also in abgeschlossene Umgebungen mit allen Dateien und Einstellungen, die zur Ausführung nötig sind. Anders als virtuelle Maschinen bringen Container kein eigenes Betriebssystem mit, sondern teilen sich den Kern des Wirtssystems. Das hält sie klein und macht sie zwischen Umgebungen austauschbar.

Wie solche Systeme im Betrieb skalieren

Weil ein Dienst in einem Container steckt, lässt er sich beliebig oft parallel starten. Ein Load Balancer verteilt die Anfragen auf diese gleichartigen Instanzen. Steigt die Last, kommen weitere hinzu, sinkt sie, werden sie wieder abgeräumt.

Fällt eine Instanz aus, ersetzt die Steuerung sie automatisch, ohne dass der Dienst als Ganzes stillsteht. In einer monolithischen Architektur wäre stattdessen ein weiterer Server nötig, auf dem die komplette Anwendung erneut aufgebaut werden müsste. Diese horizontale Skalierung ist der wirtschaftliche Kern des Ansatzes und einer der Gründe, warum die Architektur bei der Planung der IT-Infrastruktur früh festgelegt wird.

Was der Ansatz voraussetzt

Vier Bausteine gelten als tragend, nämlich Microservices, Container, automatisierte Integration und Auslieferung sowie DevOps als Arbeitsweise. Der letzte Punkt ist kein reines Technikthema, sondern verlangt, dass Entwicklung und Betrieb dieselbe Verantwortung tragen.

Ohne diese Automatisierung kehrt sich der Vorteil um, weil dutzende Dienste einzeln gepflegt, überwacht und aktualisiert werden müssen. Für kleine, selten geänderte Anwendungen bleibt eine geschlossene Architektur deshalb die einfachere Wahl.