Cloud-native Apps benötigen keine Cloud
Die Ironie ist köstlich mit dem Schlagwort des Tages: Cloud-native.
Als Erstes ist zu beachten, dass Cloud-Native trotz seines Namens keine Cloud erfordert. Ich weiß richtig? Der Name leitet sich vom architektonischen Ansatz ab, eine Anwendung zu erstellen, die auf Infrastruktur basiert und um die Konzepte der Cloud herum entwickelt wird: Elastizität, Skaleneffekte und verteiltes Rechnen. Es ist unbestreitbar das Cloud Computing, das diese Konzepte in jeden Aspekt der Anwendungsbereitstellung gebracht hat : von der App-Architektur bis zur Automatisierung, von der API-basierten Integration bis zur Infrastruktur. Cloud Computing hat die Art und Weise verändert, wie wir Anwendungen entwickeln, erstellen und bereitstellen. In der öffentlichen Cloud geborene Apps übernahmen natürlich viele der gleichen Abhängigkeiten und Eigenschaften. Somit spiegelt der Name die Etymologie des Architekturstils genau wider.
Unbestreitbar besteht auch eine Verbindung zwischen Cloud-Native und Containern. Das allein unterscheidet sie von „Born-in-the-Cloud“-Apps, die zum Erreichen ähnlicher Ziele in erster Linie auf virtuelle Maschinen und Cloud-native Dienste angewiesen sind. Cloud-native und Container sind eng miteinander verknüpft, da die zugehörigen Container-Orchestratoren (Kubernetes) das einfachste und am weitesten verbreitete Mittel sind, um Anwendungen mit der erforderlichen Infrastruktur zu koppeln, um Elastizität und damit die gewünschten Skaleneffekte zu erzielen.
In einer Cloud-nativen Anwendung werden Komponenten atomisiert, um Skaleneffekte zu unterstützen. Aus diesem Grund sind die Begriffe „Cloud-native“ und „Container“ nahezu synonym. Sie müssen in der Lage sein, bei Bedarf nur die Funktionen zu skalieren, die auch gefragt sind. Diese Art der elastischen, funktionalen Aufteilung von Anwendungen wurde traditionell durch Architekturen erreicht, die auf Layer-7-Routing (HTTP) basieren, und Cloud-Native bildet hier keine Ausnahme. Für diese modernen Anwendungen gelten die gleichen Prinzipien und sie nutzen im Allgemeinen einen Ingress-Controller (einen Infrastrukturanwendungsdienst), der die Verteilung eingehender Anfragen an die entsprechende containerbasierte Instanz einer Anwendungskomponente verwaltet.
Diese Partitionierung wird häufig auf API-Ebene durchgeführt, wo URIs API-Aufrufen zugeordnet werden, die wiederum bestimmten Containerdiensten zugeordnet sind. Die Eingangssteuerung leitet Anforderungen an den entsprechenden Containerdienst weiter, der wiederum die Anforderungen auf einen Pool von Komponenten-/Anwendungsinstanzen verteilt. Dies ist ein zweischichtiger Kuchen mit Layer 7-Eingangskontrolle (HTTP), die zur Zustellung und Erfüllung an einen guten alten Load Balancer (POLB) verteilt wird.
Darüber hinaus sind wir auf Service-Registries angewiesen, die im Grunde ein weiterer Infrastrukturanwendungsdienst sind, der erforderlich ist, um die Elastizität cloudnativer Anwendungen zu ermöglichen. Ohne einen Mechanismus zur Diensterkennung funktionieren Lastausgleich und Eingangskontrolle nicht, was wiederum die Anwendung funktionsunfähig macht.
Diese Beziehung – zwischen Komponenten, Diensten, Dienstregistern, Lastenausgleichsmodulen und Eingangskontrolle – ist die Verkörperung der Prinzipien Cloud-nativer Anwendungen. Anwendungskomponenten und Infrastruktur sind eng verknüpft, ohne jedoch fest gekoppelt zu sein. Ohne Layer-7-Routing und herkömmliche Lastausgleichsfunktionen können Komponenten keine Skaleneffekte erzielen oder die Verteilung auf verschiedene Umgebungen verlagern. Die Abhängigkeit zwischen Infrastruktur und Anwendungen ist real und von entscheidender Bedeutung für die geschäftliche Notwendigkeit, Apps bereitzustellen.
Nichts davon hängt von einer Cloud-Computing-Umgebung ab oder erfordert eine solche. Eine Cloud-native-Anwendung kann eigenständig bereitgestellt werden und wird dies häufig auch. Wenn wir uns die Daten zu Containern und ihrem Ausführungsort ansehen, stellen wir fest, dass die lokale Nutzung gegenüber öffentlichen Cloudumgebungen weiterhin im Vorteil ist.
Natürlich ist es richtig, dass Container in einer privaten (lokalen) Cloud bereitgestellt werden könnten. Und unsere eigenen Untersuchungen belegen auch weiterhin, dass die private Cloud vor Ort nach wie vor das am häufigsten verwendete Cloud-Modell ist. Mehr als drei Viertel (79 %) der Befragten in unserem State of Application Services 2019 verfügen über Anwendungen in einer lokalen, privaten Cloud, während die öffentliche Cloud mit 45 % weiterhin Schwierigkeiten hat, die Mehrheit zu erreichen.
Cloud-native Anwendungen sind eine schnell wachsende Architektur und Sie können sicher sein, dass sie in den nächsten fünf Jahren weiter wachsen wird. Das Verständnis ihrer Beziehung zu Infrastrukturanwendungsdiensten und ihrer Abhängigkeit von diesen ist ein entscheidender Faktor für die erfolgreiche Bereitstellung (und Sicherung) dieser modernen Anwendungen.