Cloud Native

Der Begriff “Cloud Native“ ist seit einigen Jahren in der IT-Landschaft vertreten und viele Unternehmen wenden die Prinzipien bereits an – zumindest teilweise. Zur Auffrischung von einigen Themen, die diesen Prinzipien zugrunde liegen, wollen wir hier einen Überblick über die Grundlagen geben. Generell umfasst Cloud Native den gesamten Softwareentwicklungszyklus mit dem Fokus auf Cloud-Infrastruktur (Public und Private Cloud). Dabei geht es darum, Anwendungen so zu entwerfen, zu entwickeln und zu betreiben, dass die Vorteile des Cloud Computing optimal genutzt werden.

Technologische Betrachtung

Wenn man Cloud Native aus einer eher technischen Perspektive betrachtet, wird man voraussichtlich mit den Konzepten in den folgenden Abschnitten in Kontakt kommen.

Container

Eine Kernidee revolutionierte das Bereitstellen und die Ausführung von Diensten. Mit Hilfe von Containern kann die Software gekapselt werden, so dass sie konsistent in verschiedenen Umgebungen und in Isolation ausgeführt werden kann. Dies löst das Problem, dass verschiedene Prozesse, die auf demselben Betriebssystem (virtuell oder physisch) laufen, unterschiedliche Abhängigkeitsanforderungen haben (z. B. Bibliothek A in v1.0 und in v2.0). Container können auch als Weiterentwicklung der Virtualisierung gesehen werden, die natürlich immer noch ihre Daseinsberechtigung in bestimmten Anwendungsfällen hat.

Weiterhin sind Container portabler und erleichtern das schnelle Ausrollen von Anwendungen zwischen Entwicklungs-, Test- und Produktionsumgebungen. Container-Images können als Archive betrachtet werden, die alle benötigten Dateien und Basiskonfigurationen bündeln. Aufgrund ihrer Leichtgewichtigkeit (im Vergleich zu VMs) können Container schnell gestartet, gestoppt und repliziert werden. Dies erleichtert das horizontale Skalieren einer Anwendung in beide Richtungen, um wechselnden Anforderungen flexibel und schnell gerecht zu werden.

Weiterhin lohnt sich auch ein Blick auf die Manifeste der 12-Factor Paradigmen. Dabei handelt es sich um eine Dokumentation, die weitere Techniken für die Entwicklung und den Betrieb von soliden Softwaresystemen im Kontext von Cloud-Native beschreibt.

Microservices-Architektur

Microservices ist ein viel diskutiertes Pattern, das häufig falsch verstanden oder umgesetzt wird. Oft verleitet bereits das Präfix “Micro” zu falschen Schlussfolgerungen. Es kann z. B. so verstanden werden, dass ein großer existierender Dienst (Monolith) einfach in viele kleine, isolierte und einzelne Funktionen umfassende Dienste zerlegt werden soll. Die eigentliche Intention dieses Architekturansatzes kommt allerdings meist von strukturellen oder organisatorischen Problemen. Zu große Teams behindern sich z. B. gegenseitig bei der Entwicklung, dem Erstellen von Releases und den eigentlichen Deployments, wenn ein immer größer werdendes Softwaresystem entsteht. Mit Hilfe von domänenorientiertem Denken können Teams und Software in fachliche Bereiche untergliedert werden. Dadurch bremsen sich kleinere Teams selbst nicht mehr aus und die Verantwortung für fachbereichsspezifische Microservice wird klar definiert. Als Nebenprodukt ergeben sich auch technische Vorteile in Form von einer unabhängigeren Weiterentwicklung, Bereitstellung und Skalierbarkeit der Dienste durch die Teams.

Service Mesh

In der Softwarearchitektur ist ein Service Mesh eine separate Infrastrukturebene, welche die Kommunikation zwischen verteilten Anwendungen hinsichtlich übergreifender Aspekte unterstützt. Technisch betrachtet schalten sich Komponenten des Service Mesh als Netzwerkproxy vor die eigentlichen Dienste, um ein- und ausgehende Verbindungen transparent mit neuer Funktionalität zu erweitern. Somit wird eine sichere und zuverlässige Kommunikation zwischen Diensten ermöglicht. Weiterhin können durch diesen Mechanismus Telemetriedaten transparent erfasst und an Auswertungssysteme weitergeleitet werden. Diese Aspekte obliegen also nicht mehr der individuellen, wiederkehrenden Implementierung in jeder Anwendung, sondern werden übergreifend als generisches Infrastrukturkonzept bereitgestellt. Aktuell bekannteste Kandidaten in diesem Bereich sind Istio und Linkerd.

Unabhängigkeit vom Cloud-Provider

Die Anwendungen sollten je nach Anwendungsfall so konzipiert sein, dass sie über verschiedene Cloud-Anbieter hinweg portabel sind. Insbesondere, wenn es um die Entwicklung von Produkten geht, die bei verschiedenen Kunden gehostet werden sollen. Der Einsatz von Containern unterstützt diese Idee eines anbieterneutralen Paradigmas bereits fundamental. Aber auch bei den architekturellen Rahmenbedingungen sollte man sich Gedanken darüber machen, welche der bestehenden Dienste eines Cloud-Anbieters genutzt werden. Proprietäre APIs von z. B. bestimmten Datenbank- oder Queueingsystemen können zu hohen Entwicklungsaufwänden und komplexen Migrationsprozessen führen, falls ein Wechsel zu einem anderen Hyperscaler erforderlich wird. Daher ist es wichtig, offene Standards zu nutzen und Open-Source-Tools zu bevorzugen, die auf verschiedenen Cloud-Plattformen funktionieren.

Im zweiten Teil dieser Beitragsserie werden wir uns auf Laufzeitaspekte wie Skalierbarkeit, Ausfallsicherheit und Sicherheit konzentrieren. Seien Sie gespannt. Lesen Sie weiter.

Autor © 2024: Marcel Hoyer – www.linkedin.com/in/marcel-hoyer-0a21a12b2/