Cloud Native Stacks – Teil 1 Grundlagen und Überblick über Cloud-native Ansätze

Will man geschäftskritische Anwendungen „Cloud Native“ machen, bedeutet das nicht selten eine komplette Neuentwicklung. Ein Blick auf Cloud Native App Stacks hilft dabei, den Aufbau und die Struktur eines möglichen eigenen Stacks besser zu planen.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Confluent Germany GmbH

Das Entwickeln und Betreiben moderner, Cloud-nativer Anwendungen im gleichen Komponenten- und Services-orientierten Entwicklungs- und Betriebs-Modell verlangt Entwicklern und Operatoren einiges ab. Eine erste Anlaufstelle, sich mit Cloud Native Stacks auseinanderzusetzen, könnte die erst vor rund einem Jahr gegründete Cloud Native Computing Foundation (CNCF) sein.

Die CNCF wurde als Unterprojekt der Linux-Foundation mit dem Ziel gegründet, die Entwicklung von Open-Source-Werkzeugen zu fördern, die Unternehmen helfen, Applikationen „cloud-ready“ zu machen. Eine zentrale Rolle spielen dabei Microservices-Architekturen und Container-Technologien.

Unternehmen können damit Cloud-Anwendungen schneller und vor allem einfacher entwickeln und ausrollen. Inzwischen sind viele namhafte Open-Source-Projekte der Cloud- und Container-Szene auf CNCF beheimatet, darunter Google Kubernetes, rtk oder containerd.

Cloud Native Computing Foundation

Erst im Frühjahr dieses Jahres stellte die CNCF auf ihrer Anwenderkonferenz CloudNativeCon in Berlin zahlreiche neue Open-Source-Projekte vor. Auch die Unterstützung kommerzieller Anbieter für die CNCF wie jüngst durch Dell-EMC lässt wenig zu wünschen übrig. Im Verwaltungsrat der Stiftung sitzen Vertreter von Google, Docker, CoreOS, Cisco und Fujitsu.

Die reine Mitgliederliste der CNCF umfasst mehr als 80 Organisationen, darunter auch kleinere Unternehmen. So stellt z. B. Jamie Dobson, CEO von Container Solutions, die strategischen Ziele der Foundation und die strategische Bedeutung Cloud-nativer Anwendungen in den Fokus seines Artikels bei Data-Center-Insider.

Die Stiftung versteht sich allerdings nicht nur als Hosting- und Social-Plattform, die Unternehmen bei der Entwicklung Cloud-nativer Anwendungen informell unterstützt; vielmehr entwickelt und kanalisiert sie auch die Einzelprojekte unter der Führung von Google zu einem Cloud-nativen Stack, der Unternehmen den Weg zu Cloud-nativen Anwendungen vorzeichnet.

Was bedeutet Cloud Native?

Als Cloud Native werden solche Anwendungen bezeichnet, die von vornherein dazu konzipiert sind, in der Cloud zu laufen, wie z. B. Microservices, selbsterhaltende Systeme oder Big-Data-Anwendungen. Im Grunde führt heute für das Entwickeln hoch skalierbarer Cloud-Anwendungen kaum ein Weg an einer Microservices-Architektur vorbei. Hierbei sind sich die Fachleute zwar weitgehend darin einig, dass wir von einer Cloud-nativen Anwendung sprechen, wenn…

• sie als verteiltes System aus Microservices realisiert ist,

• die ihrerseits in Containern paketiert sind

• und dynamisch auf den einzelnen Knoten der unterliegenden Cloud-Umgebung ausgeführt werden.

Allerdings ist das letzte Wort darüber noch nicht gesprochen, dass Container und Microservices tatsächlich unabdingbar sind, um Cloud-native Apps zu entwickeln und zu betreiben. Zumindest bieten andere Hersteller auch umfassenden PaaS-Ansätze, die den Parallelbetrieb traditioneller UND Cloud-nativer Apps ermöglichen.

Microservices

Microservices wiederum sind im Grunde nichts anderes, als eine in die Cloud portierte Service-orientierte Architektur (SOA), gepaart mit der konsequenten Umsetzung einer Komponenten-orientierten Architektur. Diese reicht von der Entwicklung über die Bereitstellung bis in den Betrieb, wobei Microservices letztlich Komponenten mit einer HTTP-Schnittstelle darstellen.

„Erst das Fortschreiben dieses Komponentenansatzes bis in den Betrieb hinein ist der eigentliche Treiber bzw. Enabler für DevOps, das letztendlich den Unterschied zwischen Softwarearchitektur und Betriebsarchitektur aufhebt“, sagt Dr. Josef Adersberger von der QAware GmbH München. Das Unternehmen ist maßgeblich an der Definition und Bereitstellung „des einen“ Cloud-Native-Stacks beteiligt, wie ihn die CNCF versteht und der sich auf Open-Source-Software konzentriert.

Dieser Cloud Native Stack soll das Bauen Cloud-nativer Applikationen wesentlich vereinfachen und besteht in der Definition von QAware aus mehreren Schichten, die sich relativ klar voneinander abgrenzen lassen. Hieraus ergibt sich die im vorangestellten Bild illustrierte Architektur eines Cloud-Native-Stacks.

Cloud-native Anwendungen werden also idealerweise auf Basis eines solchen Cloud Native Stacks entwickelt UND betrieben. In Anbetracht der zahlreichen populären Open-Source-Anwendungen, die das Cloud-Native-Umfeld derzeit bereithält und von denen viele bei der CNCF gehostet sind, sind verschiedene Cloud Native-Stacks vorstellbar, erst recht, wenn man kommerzielle Anbieter und Lösungen hinzurechnet.

Auch wenn der Begriff „Cloud Native-Stack“ im Wesentlichen von der CNCF und dem Unternehmen QAware geprägt wird, gelten folgende Überlegungen grundsätzlich; etwa die Zerlegung des Stacks in drei Schichten, die sich in nahezu jeder Ausprägung eines Cloud Native-Stacks wiederfinden.

Cluster Scheduler

Als erste Schicht ist darin der Cluster Scheduler dafür zuständig, die einzelnen Container so ressourcenschonend wie möglich auf den passenden Cloud-Knoten auszuführen. Dazu allokiert er die benötigten Ressourcen und steuert, bzw. überwacht das Ausführen des Containers auf den allokierten Ressourcen, welche wiederum selbst VMs auf einem Host, private/öffentliche IaaS-Clouds oder traditionelle Racks sein können.

Für das Ermitteln der Ressourcen verwendet der Cluster Scheduler einen passenden Algorithmus. Dieser steuert z. B., dass die benötigten Ressourcen für einen bestimmten Zeitraum zum Ausführen des Containers zur Verfügung stehen. Ein Re-Scheduling erfolgt dann, wenn z. B. an anderer Stelle passende Ressourcen frei werden. Als mögliche Cluster-Scheduler nennt der von der CNCF favorisierten Stack Apache Mesos, Docker Swarm, Hadoop YARN, CoreOS fleet und Nomad.

Cluster Orchestrator

Der Cluster Orchestrator arbeitet auf der zweiten Schicht und steuert das Ausführen sämtlicher zu einer Anwendung gehörender Container. Im Gegensatz zum Cluster Scheduler, der stets nur den einzelnen Container unabhängig von seinem Kontext „sieht“, verwaltet und überwacht der Cluster Orchestrator stets komplette Anwendungen. Dazu beauftragt der Cluster Orchestrator den Cluster Scheduler mit dem Ausführen der einzelnen Container einer Anwendung.

Mit „Überwachen“ ist gemeint, dass es in einer automatisierten Cloud-Umgebung nicht mit dem initialen Platzieren von Containern getan ist. Vielmehr muss der Cluster Orchestrator zu jedem Zeitpunkt in der Lage sein, sowohl auf eine Skalierungsanforderung, als auch auf einen Fehler zu reagieren. Die wichtigsten und bekanntesten als Cluster-Orchestrator in Frage kommenden Open-Source-Projekte sind Kubernetes, Docker Compose oder Apache Aurora. Weitere finden sich auf der GitHub-Seite des Cloud-Native-Stacks von QAware.

Microservices-Framework

Das Microservices-Framework auf der dritten Schicht des Cloud Native Stacks von QAware definiert schließlich die technische Infrastruktur, auf der Microservices implementiert und ausgeführt werden können. Daher muss eine entsprechende Lösung elastisch (horizontal skalierbar) und fehlertolerant sein. Als bekannteste Lösung für sein Microservices-Framework nennt QAware Spring Cloud mit Spring Boot, erweitert um verschiede Cloud-Module, also ein relativ komplexes Tool-Pack.

(ID:44736314)