Herausforderungen für Anwendungsbereitstellungsdienste in Microservices-basierten Anwendungen

Auf der anderen Seite laufen Anwendungen, die auf traditionellen Ansätzen beruhen, auf weniger VMs als die gleiche Anwendung, wenn sie in Microservices aufgeteilt ist. Durch den Wechsel zu Microservices könnte eine typische Anwendung mit nur drei Servern - einem für PHP, einem für Java und einem für die Datenbank - potenziell 30 Dienste auf einem Cluster mit vielleicht 12 Knoten umfassen. Durch die dynamische Skalierbarkeit der Server auf der Grundlage der Verkehrslast und der Replikation für die Serviceverfügbarkeit werden weitere VMs hinzugefügt. Docker-Container und Cluster-Manager sowie Betriebssysteme für Rechenzentren sind die Antwort auf diese Herausforderung.

Dies hat zur Folge, dass sowohl der Verkehr der API-Dienste im Web als auch der Ost-West-Verkehr im Vergleich zum Nord-Süd-Verkehr in einem herkömmlichen Rechenzentrum enorm zunimmt. Amazon.com verwendet in der Regel zwischen 100 und 150 APIs für das Rendering einer seiner Seiten. Bei Netflix verursachen Microservices 5 Milliarden API-Anfragen pro Tag, von denen 99,7 Prozent intern sind, wie Daten aus dem Jahr 2014 zeigen. In ähnlicher Weise macht der Mid-Tier-API-Verkehr von salesforce.com mehr als 60 Prozent des von den Anwendungsservern abgewickelten Datenverkehrs aus (Daten von 2013).

Die Interaktionen zwischen Microservices, bei denen einer einen anderen aufruft, führen zu verkehrsbedingten dynamischen Abhängigkeiten, die viel komplexer sein können als explizit sichtbare Microservice-Abhängigkeiten, die sich aus Netzwerkparametern oder Referenzen im Code ergeben. Wann immer Probleme auftauchen, ist es wichtig, die Reihenfolge zu verstehen, in der die Dienste für diese spezifische Transaktion aufgerufen wurden. Die Dokumentation und/oder Visualisierung der fließenden Anwendungstopologie ist nicht einfach zu bewerkstelligen.

Die Geschwindigkeit von Software-Upgrades stellt eine weitere Herausforderung dar. Mit der Zunahme kleinerer Microservices, die von verschiedenen Entwicklern betreut werden, und der Verwendung von Methoden zur kontinuierlichen Bereitstellung kann sich die Anwendung als Ganzes viel schneller ändern, selbst wenn die Änderungsrate zweiwöchentlich ist. Es ist bekannt, dass Amazon, Github, Facebook und andere mehrmals am Tag Produktionscode bereitstellen. Die Herausforderung besteht also darin, den Wechsel des Produktionsverkehrs von einer älteren zu einer neueren Version des Produkts zu automatisieren. In der Tat muss man mit dem Lebenszyklus dieser Microservices arbeiten, die eine kurze Lebensdauer haben können, um vorübergehende Lasten und einmalige funktionale Anforderungen zu bewältigen. AWS Lambda zum Beispiel kann ephemere Dienste mit einer Lebensdauer von 200 ms erstellen!

Je verteilter und vernetzter eine Anwendung ist, desto größer ist die Notwendigkeit, die Überwachung im Auge zu behalten. Metriken, Analysen, Steuerungsmaßnahmen und Automatisierung sind das Lebenselixier für die Wartung eines solchen Systems. Beachten Sie, dass ein Betriebssystem leicht über 100 Metriken generieren kann und jede App-Server-Instanz mehr als 50 Metriken pro Sekunde erzeugen kann. Das bedeutet, dass eine typische Bereitstellung leicht Tausende von Metriken pro Sekunde erzeugen kann. Jede Infrastruktur zum Sammeln, Bereinigen, Zusammenstellen, Korrelieren und Erzeugen von umsetzbaren Kontrollen aus diesen Metriken muss über Abstraktionen und Identifikatoren verfügen, die für eine sinnvolle Nutzung der Daten erforderlich sind.

Konsequenzen für Application Delivery Services

Bei der Anwendungsbereitstellung geht es traditionell um die Verwaltung der betrieblichen Aspekte einer Anwendung, die in einem Rechenzentrum bereitgestellt wird, und um die Bereitstellung eines zuverlässigen Zugangs für jeden Kunden zu jeder Anwendung von jedem Ort der Welt aus. Sie bietet in der Regel Dienste wie Lastausgleich, Verkehrsmanagement und Sicherheit. Auf virtuellen und Cloud-Infrastrukturen sind sie als reine Software-Images verfügbar. Ihre Sicht auf die Anwendungs- und Verkehrsflussmuster ist jedoch traditionell und konzentriert sich auf monolithische dreistufige Architekturen, die Clients hauptsächlich außerhalb des Rechenzentrums bedienen und auf einem traditionellen Appliance-Formfaktor basieren.

Das Microservice-Phänomen hat sich stark ausgebreitet und ermöglicht es den Anwendungseigentümern, mehr Kontrolle über ihre eigenen Anwendungsbereitstellungsdienste zu erlangen, in der Regel unter Verwendung von Open-Source-Tools wie NGINX und HAProxy, anstatt einen Edge-basierten Application Delivery Controller (ADC) zu verwenden. Das zentrale IT-Team konzentrierte sich in der Regel auf die Edge-Geräte und die Verwaltung des ein- und ausgehenden Datenverkehrs und weniger auf den Nord-Süd-Verkehr auf der mittleren Ebene, vor allem aufgrund der bestehenden Architekturen, Kosten und Komplexität. Dieser Trend zur Nutzung von OSS entkoppelt die zentrale IT und führt zum Entstehen von "Schatten-IT"-Gruppen mit ihren eigenen Ad-hoc-Richtlinien.

Anwendungsbereitstellungsdienste erfordern in diesem Zusammenhang ein grundlegendes Umdenken. Erforderlich ist eine hochgradig verteilte und skalierbare Architektur mit einer Infrastruktur, die kontinuierlich mit dynamischen Änderungen arbeitet, die von allen Beteiligten in Echtzeit erkannt werden müssen. Das Verkehrsmanagement muss in der Lage sein, Upgrades mit automatischen Verkehrsübergängen und Rollbacks zu unterstützen. Metriken müssen von verschiedenen Instanzen gesammelt und in vielen Dimensionen korreliert werden, je nachdem, wie die Microservices der Anwendung definiert sind. Nachfolgend sind einige der wichtigsten Herausforderungen aufgeführt, denen sich Anwendungsbereitstellungsdienste für Microservices stellen müssen:

• Umgang mit der Abhängigkeit von miteinander verknüpften dynamischen Diensten
• Verteiltes Verkehrsmanagement
• Verteilte Sicherheit
• Operative Intelligenz
• Fehlerbehebung, Transparenz und Analyse auf Anwendungsebene
• Behandlung der Auswirkungen von Ausfällen in dynamischen Topologien bei harten und weichen Ausfällen

Die erste Herausforderung eines solchen App-Bereitstellungsdienstes besteht darin, sich in eine dynamische und verteilte App-Topologie einzufügen. Er muss die Einfügung des Dienstes als Cluster von Proxys orchestrieren und sie mit der Infrastruktur und den Netzwerkartefakten wie Sicherheitsgruppen, Skalierungsgruppen usw. verbinden. Und angesichts der Vergänglichkeit physischer Ressourcen muss es auf einer deklarativen Beschreibung der Anwendung beruhen, die Topologie und die Netzwerkparameter im Einsatzzustand operativ ermitteln und in der Lage sein, sie zu ändern.

Ein wichtiger Punkt, den herkömmliche Software-ADCs nicht berücksichtigen, ist die Notwendigkeit, den Datenverkehr und die Last in einem verteilten Cluster von Service Delivery Proxies zu korrelieren, um das System richtig zu steuern. Das nachstehende Diagramm veranschaulicht diesen Punkt, bei dem eine App-Server-Instanz Datenverkehr von vielen ADCs empfangen kann, während andererseits eine ADC-Instanz Datenverkehr an viele App-Server weiterleitet. Das bedeutet, dass jeder ADC berücksichtigen muss, was andere ADCs mit einem bestimmten App-Server machen.

Architektur für Cluster von ADCs und Anwendungs-Microservices

Die Herausforderung besteht also darin, einen unveränderlichen Überblick über eine Anwendung und ihren Datenverkehr zu erhalten, während die grundlegenden Ressourcen dynamisch und zudem verteilt sind. Um dies zu erreichen, müssen wir an Methoden zur Erkennung dieser Beziehungen über eine Registrierung und benachrichtigungsbasierte Strategien arbeiten, gefolgt von einer leistungsstarken Visualisierung für den Systembetreiber. Außerdem benötigen wir eine Möglichkeit, Richtlinien auf die abstrakte Ansicht der Anwendung anzuwenden. Containerisierte Microservices schaffen ihre eigenen netzwerkbezogenen Herausforderungen, die diese Systeme angehen müssen.

Verteilte Systeme haben viele Fehlerpunkte mit komplizierten Abhängigkeiten, und einige werden unweigerlich ausfallen. Aufgrund der asynchronen und sich dynamisch verändernden Verbindungen und Interaktionen zwischen vielen verschiedenen Einheiten kann es schwierig sein, schwer zu findende Fehler aufzuspüren. Ausfälle können sowohl "weich" oder vorübergehend als auch "hart" oder endgültig sein. Schlimmer noch, einfache Ausfälle in einer Komponente können manchmal eine Kaskade von Ausfällen in den voneinander abhängigen Microservices der Anwendungsinfrastruktur auslösen. Die Wiederherstellung bei schwerwiegenden Ausfällen muss dynamisch und schnell erfolgen, d. h. es müssen sowohl Signale für bevorstehende Ausfälle ausgegeben als auch die ausgefallenen Instanzen zeitnah wiederhergestellt werden.

Microservices versprechen viel und können zu einer erheblichen Flexibilität der Anwendungen und einer kürzeren Markteinführungszeit führen. Herkömmliche Architekturen müssen sich rasch weiterentwickeln und die Mechanismen zur Bereitstellung von Anwendungen müssen Schritt halten. Kurz gesagt: Anwendungsdienste für das Zeitalter der Microservices erfordern ein neues Denken und eine neue Architektur für die sich ändernden Anforderungen.