Seite 2: Cloud-Ansätze und -Prinzipien

Inhaltsverzeichnis

Die Cloud-Native Architecture steht für die konsequente Nutzung von Cloud-Services. Sie umfassen dabei alle Dienste, die ihrerseits unterschiedliche Aspekte der Cloud-Native Architecture unterstützen. Beispiele dafür sind Services, die den Microservices den Zugriff auf Datenbanken bereitstellen. Oder unterstützende Services zur Auslieferung der Microservices, beispielsweise Jenkins.
Aufgrund der Vielzahl der Cloud-Services betrachtet dieser Artikel nur diejenigen, die den Microservices die Laufzeitumgebung zur Verfügung stellen. Hierbei lassen sich fünf verschiedene unterliegende Cloud-Ansätze von IaaS bis SaaS unterscheiden (s. Abb. 1). Sie stellen jeweils einen anderen Umfang an IT-Ressourcen für den Aufbau der Laufzeitumgebung bereit. Die Frage ist also: Welcher Cloud-Ansatz für die Laufzeitumgebung ist der beste für die individuell benötigte Cloud-Native Architecture?

Nur vier der in der Einführung vorgestellten sieben Prinzipien der Cloud-Native Architecture sind für die Auswahl des richtigen Cloud-Ansatzes überhaupt von Bedeutung. Dazu gehören Service-Mesh, Containerisierung, Scheduling und Orchestrierung sowie Clustering. Alle anderen Prinzipien sind durch eine andere Art von Cloud-Service abgedeckt (Abb. 2).

Bevor sich die unterschiedlichen Cloud-Ansätze überhaupt bewerten lassen, ist noch eine Abgrenzung notwendig. Der Artikel betrachtet stets eine Public Cloud, wie sie beispielsweise Amazon, Google oder Microsoft anbieten. Entscheidend ist, dass diese Cloud-Provider versprechen, quasi unbegrenzt Ressourcen bereitzustellen. Exakt diese Anforderung stellt die Cloud-Native Architecture, womit die Public Cloud die einzig sinnvolle Wahl ist.

Folglich lässt der Artikel Private Clouds, die von Unternehmen On-Premise oder von anderen Anbietern aufgebaut sind, außer Acht. Sie sind meist nicht in der Lage, unbegrenzt Ressourcen anzubieten, und daher in ihren Möglichkeiten eingeschränkt.

Als Referenz für eine Public Cloud dienen im Artikel die Amazon Web Services (AWS), da sie mit 33 Prozent den größten Marktanteil besitzen und sich andere Anbieter teilweise daran orientieren.

Der Dogmatismus

Viele Unternehmen setzen dogmatisch auf den Cloud-Ansatz der Infrastructure as a Service (IaaS), um ihren Microservices eine Laufzeitumgebung bereitzustellen. Damit müssen sie die gesamte Laufzeitumgebung für Containerisierung, Scheduling und Orchestrierung, Clustering und Service-Mesh selbst aufbauen. Denn IaaS liefert lediglich Computer- und Network-Services. Dieser Ansatz hat Vorteile, etwa die damit verbundene Flexibilität, aber auch Nachteile, etwa die gestiegene Komplexität. Vermutlich setzt sich dieser Cloud-Ansatz deshalb häufig durch, weil IaaS bereits als typischer Baustein gilt – oder aber die IT damit ihren politischen Einfluss im Unternehmen stärken kann.
Aus Sicht der IT-Architektur ist der IaaS-Ansatz aber nicht immer die beste Wahl. Schon gar nicht, wenn ausschließlich dieser über das gesamte Unternehmen ausgerollt wird. Denn auch andere Kriterien, beispielsweise Kosten oder benötigte Zeit für den Aufbau der Laufzeitumgebung, sollten berücksichtigt sein. Schließlich erfordern der Aufbau und der Betrieb von Laufzeitumgebungen eben viel Zeit, was wiederum das Budget belastet.

Bewertungsmatrix

Finden lässt sich der passende Cloud-Ansatz für die Laufzeitumgebung ganz klassisch: Indem die IT-Architekten genauso vorgehen wie in allen anderen Auswahlsituationen auch. In der Regel treffen sie mittels einer Bewertungsmatrix die Auswahl der passenden Technik. Für das Erstellen einer solchen Matrix müssen die verschiedenen Cloud-Ansätze hinsichtlich möglichst objektiver Kriterien bewertet werden. Liegt dann eine fertige Bewertungsmatrix vor, können IT-Architekten die Bewertungen abhängig vom eigenen Anwendungskontext gewichten und eine Auswahl treffen.