Cloud Native: Laufzeitaspekte für skalierbare Anwendungen

Cloud Native: Laufzeitaspekte

Nach der Einführung der technischen Konzepte in Teil eins dieser Serie bezüglich Implementierung und Architektur geht es im nächsten Schritt darum, die Hosting-Möglichkeiten im Kontext Cloud zu verstehen. Die meisten der folgenden Punkte sind in den bekannten Hyperscaler-Plattformen (AWS, Azure, GCP, …) allgemein verfügbar.

Dynamic Orchestration

Mit Tools wie Kubernetes kann die Bereitstellung, Skalierung und Verwaltung von containerisierten Anwendungen automatisiert werden. Im Vergleich zu früheren Vorgehensweisen beim Betreiben von Software gibt es jetzt einen wesentlichen Unterschied: der gewünschte Zielzustand des Laufzeitsystems wird deklarativ mit Hilfe von Ressourcenobjekten beschrieben, welche die Speicher-, Netzwerk- und ausführungsbezogenen Komponenten definieren. Kubernetes im Speziellen versucht, den gewünschten Zielzustand herzustellen und arbeitet dabei intern mit einer Endlosschleife. Dieses Vorgehen ermöglicht “defekte” Zustände zu erkennen und zu reparieren, um dem vorgegebenen Sollzustand gerecht zu werden. Systeme können sich also automatisch von Fehlern erholen, indem sie beispielsweise Container neu starten oder den Datenverkehr umleiten.

Dieses Konzept lässt sich sehr gut mit dem GitOps-Ansatz kombinieren. Dessen Kernidee ist, die Zielzustände in Dateien mit den Ressourcendefinitionen in Source Control-Repositories zu verwalten und Zustandswechsel durch Commits auszulösen. Die versionierten Datenquellen werden wiederum von Gitops-Operatoren wie ArgoCD oder flux überwacht. Bei neuen Commits werden die Änderungen als aktualisierte Zustandsdefinitionen auf einen Kubernetes-Cluster ausgerollt, wo weiterführend das eigentliche Laufzeitsystem angepasst wird.

Elastizität

Elastizität beschreibt die Fähigkeit, Ressourcen dynamisch, je nach Bedarf nach oben oder unten zu skalieren. Dadurch werden zum einen die Verfügbarkeitsanforderungen (Betriebszeit) für einen Dienst erfüllt, aber auch Kosten und Leistung optimiert. Dieses Konzept erfordert Überlegungen auf vielen Ebenen der Softwareentwicklung und auch der Architektur der Ausführungsumgebung, wie z. B.:

• Welche Zustände hat ein Dienst und können diese auch in verteilten Instanzen gut funktionieren?
• Greifen verteilte Anwendungen auf die gleichen Ressourcen, wie zum Beispiel Datenbanken zu und können mit Transaktionen und Locks umgehen?
• Können häufig genutzte Daten an zentraler Stelle hochverfügbar zwischengehalten werden, um die Last auf Datenbanken zu senken?

Daneben gibt es weiterhin Möglichkeiten, die Skalierung der Anwendungsinstanzen oder gar der verwendeten Hardwareressourcen (VMs) anhand von Metriken zur Auslastung eines Systems komplett zu automatisieren.

Fehlertoleranz und Überwachung

Aufgrund der verteilten Bereitstellung von Microservices müssen die Anwendungen in vielerlei Hinsicht fehlertolerant (resilient) sein. Zum Beispiel sollte ein aufrufender Dienst nach kurzer Wartezeit versuchen eine fehlgeschlagene Anfrage zu wiederholen. Im Gegenzug sollte ein Service sich seinerseits vor unerwünschten DDoS-Attacken schützen und sogenannte Quotas einsetzen. Unabhängig von Cloud Native, ist es generell eine gute Praxis, fehlertolerante Software zu entwickeln und Ausnahmen/Fehler entsprechend zu behandeln, um die Stabilität des Dienstes zu gewährleisten

Betrachtet man alle oben genannten Punkte, wird die Architektur offensichtlich komplexer. Dies unterstreicht die erhöhte Notwendigkeit, das System von Grund auf übersichtlich zu strukturieren und zukunftssichere Entscheidungen zu treffen, bevor ein Dienst in kleinere aufgeteilt wird. Die Kombination aus Elastizität und dem dynamischen Hosting-Modell mit Kubernetes erfordert umfassende Metriken, sowie Protokollierungs- und Tracing-Mechanismen in der Anwendung und Infrastruktur. Dies erlaubt einen Einblick in die Leistung und den Zustand der Anwendung. Ein System mit Echtzeit-Feedback ermöglicht es den Softwarebetreibern, Probleme schnell zu erkennen, Lösungen zu finden und die Fehler zu reparieren.

Security

Angesichts der häufigen Nachrichten über kompromittierte Systeme und Cyberangriffe gewinnen sicherheitsrelevante Themen zunehmend an Bedeutung. Neben Aspekten wie Fehlertoleranz und Überwachung müssen auch hier bestimmte Praktiken frühzeitig in den Entwicklungszyklus integriert werden. In der Phase von Continuous Integration & Deployment (CI/CD) helfen Tools bei automatisierten Tests und Scans nach Schadsoftware. Aber auch die Laufzeitumgebung erfordert ein gutes Konzept, ein geeignetes Netzwerk-Setup und eine kontinuierliche Überwachung, um sensible Daten und die Infrastruktur zu schützen.

Wichtige Paradigmen in diesem Zusammenhang sind das “Zero Trust Model” und das “Principle of least privilege”. Dabei geht man davon aus, dass Benutzern und Geräten nicht vertraut wird und nur die notwendigen Berechtigungen vergeben werden sollten. Darüber hinaus sollten potenzielle Sicherheitsüberlegungen auf allen relevanten Ebenen (Netzwerk, die Implementierung selbst, externe Ressourcen, usw.) angestellt werden. Ein guter Ausgangspunkt, um seinen aktuellen Software-Stack mit den allgemeinen Empfehlungen abzugleichen, ist die Liste der OWASP Top Ten.

In Teil drei dieser Beitragsserie werden wir uns auf organisatorische Aspekte wie DevOps und die kontinuierliche Weiterentwicklung und Deployments (Continuous Integration and Development, CI/CD) konzentrieren. Bleiben Sie dran. Lesen Sie weiter.

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