Cloud-native Applikationen entwickeln

Seite 3: Monitoring für schnelle Bereitstellungszyklen

Inhaltsverzeichnis

Während der frühen Phasen der Cloud-Migration konzentriert sich das Monitoring meist auf die Ermittlung von Daten zur Performance der Anwendung auf der neuen Plattform beziehungsweise auf Vergleiche zwischen der alten und der neuen Produktionsumgebung. Idealerweise sollte das Monitoring-Tool aber schnelle Bereitstellungszyklen durch das frühzeitige Erkennen von Problemen unterstützen und den Entwicklern exakt jene Programmzeilen anzeigen, die ein fehlerhaftes Verhalten auslösen.

Obwohl ein Lift-and-Shift-Ansatz bei monolithischen Anwendungen eine schnelle Migration erlaubt und kurzfristige Kosten sparen kann, steigen die laufenden Betriebskosten überproportional, weil die Applikation nicht für Skalierungsmechanismen in der Cloud optimiert wurde. Wichtiger noch: Mit großen Monolithen lassen sich Innovationszyklen im Wochentakt nicht realisieren. Eine Microservice-Architektur kann Abhilfe schaffen.

Nutzt man sie, bestehen die Anwendungen aus kleinen, unabhängigen Diensten. Diese sind lose miteinander verbunden und kommunizieren über APIs (Application Programming Interface). Das Aufbrechen eines bestehenden Monolithen in Microservices ist mitunter eine schwierige Angelegenheit, weil die einzelnen Komponenten in oft unbekannter Weise miteinander interagieren. Bei der Entscheidung, welche Bestandteile zuerst als Microservices herauszulösen sind, gehen Unternehmen oft pragmatisch vor. So werden zum Beispiel jene Komponenten zuerst neu implementiert, die ohnehin wegen ihrer Mängel neu zu schreiben sind.

Die Aufteilung in kleine Services bedeutet auch, dass die Entwicklungsteams nicht mehr voneinander abhängig sind. Sie können damit selbst entscheiden, wann sie eine neue Version ihres Service herausgeben. Diese Flexibilität steigert jedoch die Komplexität: Es wird immer schwieriger nachzuverfolgen, welche Versionen welcher Services gerade live sind. Automatische Build-Prozesse und Integrationstests als Teil der CI/CD-Pipeline sind unabdingbar.

Für Microservice-Architekturen eignen sich Container-Umgebungen. Im Gegensatz zur Virtualisierung per Hypervisor laufen Container, die sich auf einem Host befinden, auf demselben, gemeinsam genutzten Betriebssystem-Kernel. Damit bilden sie eine schlanke Umgebung und ermöglichen Prozessisolation, sodass die Services völlig unabhängig voneinander laufen. Jeder Container enthält für Letztere wichtige Komponenten wie Laufzeitumgebung, Konfiguration, Bibliotheken und den eigentlichen Code für den Microservice. Einmal entwickelt, können die Dienste dadurch überall laufen.

Anstelle von IaaS bei monolithischen Applikationen ist für Microservices eine anderer Ansatz nötig: Platform as a Service (PaaS). Er bietet eine Plattform-Abstraktion, um Anwendungen einfacher installieren und betreiben zu können. Der Einsatz von PaaS und Containern hilft bei der Verschlankung des Freigabeprozesses, wodurch sich neuer Code schneller produktiv einsetzen lässt. Je mehr Services aber in eigene Container abgespalten werden, desto schwieriger gestaltet sich die Orchestrierung und Koordination. Um Cloud-Ressourcen effizient zu nutzen und die Widerstandsfähigkeit zu verbessern, wird Load Balancing zum Verteilen der Workloads über mehrere Service-Instanzen eingesetzt. Zudem stehen in der Regel unterschiedliche Health-Management-Verfahren für automatische Ausfallsicherung und Reparaturen zur Verfügung. So gut wie alle gängigen PaaS-Implementierungen (z.B. Amazon AWS Elastic Beanstalk, Azure Cloud Services, Red Hat OpenShift, Cloud Foundry, Google App Engine) bieten entsprechende Funktionen an.

Die größten Herausforderungen bei der Einführung von Microservices sind gemäß der Umfrage von O'Reilly und Dynatrace die Integration von Altsystemen, die Bewältigung der Komplexität durch die gegenseitigen Abhängigkeiten der Microservices, Technologiereife und die Skalierung von Anwendungsinstanzen. Application Monitoring bietet in vielen Fällen solide Datengrundlagen zum Bewältigen dieser Herausforderungen oder zum Optimieren der Umstände.

  • Granularität und Lokalität: Das Bestimmen des Funktionsumfangs und die Abgrenzung von Microservices innerhalb einer Applikation ist ein nicht-deterministisches Problem für Softwarearchitekten. Monitoring-Daten können empirisch zeigen, welche Services intensiv miteinander kommunizieren. Entsprechend lassen sich Services verschmelzen oder in physischer Nähe zueinander platzieren (z.B. Kubernetes Pods).
  • Remote Service Calls und Netzwerkmonitoring: Während Monolithen Funktionsaufrufe im Speicher abarbeiten, werden sie in einer Microservice-Applikation über das virtuelle Netzwerk abgewickelt. Netzwerk-Overheads und Latenzzeiten rücken damit in den Mittelpunkt und lassen sich messen.

Moderne, integrierte Monitoring-Software ermöglicht überdies die Überwachung PaaS-spezifischer Funktionen und damit die Unterscheidung von Applikations- und Plattform- beziehungsweise Infrastrukturproblemen. Das umfasst das Überwachen von Containern und den darin laufenden Services.

In Cloud-Umgebungen ist nichts mehr statisch. Das System skaliert Services gleichzeitig lastenabhängig hoch oder herunter, terminiert oder startet sie. Resilienzmechanismen der Cloud-Plattform oder Microservices (z.B. Netflix OSS Circuit Breaker) ermöglichen selbstheilende Systeme. Unterschiedliche Versionen von Microservices können parallel laufen, und Netzwerke sowie Infrastruktur lassen sich durch Software definieren.