Acht Gründe, warum die Zukunft der Container-Skalierung Service Mesh ist

Microservices eignen sich hervorragend für eine schnellere Entwicklung, die Komplexität dieser Architekturen liegt jedoch in der für Microservices wichtigen Kommunikation zwischen den Diensten.

Derzeit gibt es mindestens drei verschiedene Architekturoptionen zum Skalieren containerisierter Microservices . Jede davon basiert – wie alle Skalen – auf einem Proxy-basierten Load Balancer. Jedes bringt seine eigenen Herausforderungen mit sich. Einige davon sind auf die einfache Tatsache zurückzuführen, dass die Skalierung innerhalb von Containerumgebungen häufig auf IP-Tabellen basiert und deren Kompatibilität mit allem oberhalb der herkömmlichen Netzwerkebenen (also IP und TCP) eingeschränkt ist.

Alle diese Proxys bieten dieselbe Kernfunktionalität: die Skalierung der Dienste, die in der gesamten Container-Umgebung verteilt sind. Das Verrückte ist, dass Dienste vergängliche Konstrukte sind. Sie existieren eigentlich nicht – außer in den Ressourcendateien (Konfigurationsdateien), die sie definieren. Problematisch bei den auf IP-Tabellen basierenden Skalierungslösungen ist, dass es sich bei diesen Diensten um Konstrukte der Schicht 7 (HTTP) handelt, die häufig als „Backend“ für einen einzelnen API-Aufruf und nicht für eine ganze Application dienen.

Applications, wie wir sie kennen, können von der Clientseite aus als eine einzige, ganzheitliche Konstruktion erscheinen. In Wirklichkeit bestehen sie aus vielen verschiedenen (und verteilten) Mikroservices. Einige dieser Dienste sind rein interner Natur und für die Nutzung durch andere Dienste konzipiert. Das bedeutet eine Menge Dienst-zu-Dienst-Kommunikation innerhalb der Containerumgebung.

Sie benötigen in diesen Umgebungen L7-Routing (HTTP), da alles APIs über HTTP/HTTP2 sind. Sie benötigen außerdem eine konsistente Sicherheitshaltung, Authentifizierung und Richtliniendurchsetzung. Nichts davon wird mit einem auf IP-Tabellen basierenden Ansatz passieren.

Wie immer kommt Open Source zur Rettung. Um diese Herausforderungen zu bewältigen, sind mehrere Open-Source-Service-Meshes entstanden. Wie bei vielen Open-Source-Projekten werden diese Service-Meshes (z. B. Istio ) durch Projekte wie Aspen Mesh um Funktionen (und Support) erweitert, die Lösungen auf Unternehmensebene bereitstellen.

Diese erweiterten Bemühungen konzentrieren sich auf die Lösung der acht Herausforderungen, denen Unternehmen gegenüberstehen, wenn sie Microservices in Containern bereitstellen.

Dies sind die acht Herausforderungen und wie ein Service Mesh sie bewältigen kann:

1. Erstellen – Dies ist eine der Herausforderungen, da ein Service Mesh wenig zu bieten hat, außer Richtlinien in CI/CD-Toolchains zu integrieren und ein deklaratives Konfigurationsmodell sicherzustellen, sodass das Service Mesh als Infrastruktur als Code behandelt werden kann.
2. Test und Integration – Ein Service Mesh kann hier helfen, indem es eine einheitliche Richtlinie zwischen Entwicklung, Test, Produktion usw. gewährleistet. Manche Organisationen möchten stufenweise Bereitstellungen vollständig vermeiden. Dieser Ansatz hat in der Vergangenheit gut funktioniert, stellt jedoch eines der Hindernisse dar, die zu Latenzen im Bereitstellungsprozess führen.  Diese Leute suchen nach einer Möglichkeit, Dienste direkt in der Produktion bereitzustellen und Verkehrssteuerungs- und Rollback-Mechanismen einzusetzen, um mit Fehlern umzugehen.  
3. Versionierung – Service Mesh kann als grundlegendes API-Gateway fungieren, um den Datenverkehr basierend auf Variablen wie der API-Version weiterzuleiten und sogar Versionen zu übersetzen, um bei Übergangsphasen der API-Version zu helfen. Client-Upgrades – insbesondere bei Apps im Consumer-Bereich – können nicht immer erzwungen werden, sodass Anfragen für mehrere Versionen eingehen. Ein Service Mesh kann Anfragen für ältere API-Versionen in die neuesten übersetzen und so die Kosten und den Aufwand für die Wartung mehrerer Versionen derselben API reduzieren.
4. Bereitstellen – Dank der Fähigkeit, fließend HTTP zu sprechen, eignet sich ein Service Mesh hervorragend für Blue/Green-Bereitstellungen , Canary-Tests und Verkehrssteuerung.
5. Protokollierung – Die verteilte Protokollierung ist immer ein Problem und in Umgebungen, in denen Instanzen über sehr unterschiedliche Zeiträume hinweg existieren, ist sie noch problematischer. Ein Service Mesh bietet einen gemeinsamen, zentralen Ort zur Implementierung der Protokollierung sowie die Möglichkeit, Funktionen wie die Anforderungsverfolgung auszuführen.
6. Überwachung – Im Mittelpunkt der Skalierung steht die Überwachung. Zwar können Applications bestimmte Funktionen (Wiederholungsversuche, Unterbrechung der Stromkreise usw.) implementieren, um mit dem unvermeidlichen Ausfall eines Dienstes umzugehen, doch stellt dies eine Belastung für die Application dar, die sie nicht tragen sollte. Ein Service Mesh übernimmt die Last der Service-zu-Service-Kommunikation und bietet einen Ort für die Überwachung. Das Ziel besteht darin, sich in der Produktion auf MTTD und MTTR zu konzentrieren, da der Betrieb in der Produktion schwierig ist und Fehler unvermeidlich sind.
7. Debuggen – Je komplexer ein System ist, desto schwieriger ist die Fehlerbehebung. Ein Service Mesh kann bei der Ursachenanalyse helfen, mithilfe von Analyse- und Telemetriedaten Statistiken und Benachrichtigungen vor Fehlern bereitstellen und Container unter Quarantäne stellen, anstatt sie zu löschen, damit sie gründlich untersucht werden können. Dies ist insbesondere in Fällen hilfreich, in denen der Fehler auf langsame Speicherlecks zurückzuführen ist.
8. Netzwerk – Das Netzwerk bleibt für Container von entscheidender Bedeutung, vielleicht sogar noch mehr als in weniger komplexen Umgebungen. Der Wunsch, Dienste von diesem Netzwerk zu abstrahieren, bringt viele bewegliche Teile mit sich, die Sie nicht in jedem Dienst implementieren möchten: Service Discovery, SSL- und Zertifikatsverwaltung, Leistungsschalter, Wiederholungsversuche, Integritätsüberwachung usw. Das Ziel von Microservices bestand darin, „lokal und klein zu programmieren“. Die Notwendigkeit, netzwerkbezogene Funktionen einzubinden, bläht die Microservices auf und führt zu zusätzlicher architektonischer und technischer Schuld. Ein Service Mesh übernimmt diese Funktionen und bietet die gewünschte Skalierbarkeit und Sicherheit, ohne die Entwicklung zu verlangsamen.

Service Mesh ist eine spannende Weiterentwicklung, die moderne Prinzipien von Cloud und Containern mit den soliden Grundlagen der Skalierung kombiniert. Es ist zu erwarten, dass Service Mesh an Bedeutung gewinnen wird, da die Nutzung von Containern und die Nachfrage nach Skalierbarkeit und Support auf Unternehmensebene im Jahr 2018 weiter zunehmen.