Service Mesh Mania: Auswahl zwischen Aspen Mesh und NGINX
Zusammen mit dem größeren Container-Ökosystem schreiten auch die Service Meshes weiter voran und werden ausgereifter. Wir stehen allerdings noch am Anfang und es gibt eine Vielzahl von Ansätzen, die zur Lösung des Problems der Verwaltung des Containerverkehrs mithilfe von Service Meshes eingesetzt werden.
Wir (das ist das „Wir“ des Unternehmens) wurden im Vorfeld unserer offiziellen Übernahme von NGINX in diesem Frühjahr mit vielen Fragen konfrontiert. Mehrere von ihnen konzentrierten sich auf Überschneidungsbereiche in Technologie und Lösungen. Schließlich bieten sowohl NGINX als auch F5 proxybasierte Lösungen zur Anwendungsbereitstellung an. Sowohl NGINX als auch F5 bauen ein Service-Mesh. Die Frage war, wer würde gewinnen?
Denn so läuft das bei Akquisitionen häufig.
Wie mein Gegenüber von NGINX und ich oft betonten, waren die Technologien, auf die wir uns überschnitten, unserer Einschätzung nach eher eine Ergänzung als ein Wettbewerb. Das gilt auch für unsere Service-Mesh-Lösungen.
Unsere Logik ergibt sich aus einer gemeinsamen Vision der Anwendungsbereitstellung. Wir sind uns beide bewusst, welche Auswirkungen Container, Clouds, Microservices und eine Vielzahl von Sicherheitsverstößen auf die Architekturen und Modelle zur Anwendungsbereitstellung haben. Ebenso wenig gibt es mehr „einen Datenpfad zur Bereitstellung aller Anwendungen“ und auch nicht mehr „ein Anwendungsbereitstellungsmodell zur Bereitstellung aller Anwendungsdienste“. Die Cloud führt mehrere Datenpfade ein. Container führen einen neuen Datenpfad ein. Beide erweitern die mögliche Platzierung von Anwendungsdiensten von einem netzwerkbasierten Proxy (einem ADC) auf eine lange Liste von Standorten, die vom Client über das Netzwerk und den Server bis hin zum Container und der Cloud reicht.
Wie wir bereits in einem Beitrag zu Architekturen in unserer Reihe „Bridging the Divide“ festgestellt haben, hängt die Entscheidung, wo und wie Anwendungsdienste bereitgestellt werden, von vielen Faktoren ab. Es handelt sich nicht nur um eine Entscheidung zwischen Anbieterimplementierungen oder „Unternehmen versus FOSS“. Es ist eine Entscheidung, bei der auch der Standort (Cloud oder vor Ort), das Betriebsmodell und sogar die einfache Implementierung im Vergleich zur erforderlichen Funktionalität berücksichtigt werden müssen. Angesichts der Breite des Bereitstellungspfads ergeben sich dadurch mehrere Optionen zum Einfügen von Anwendungsdiensten.
Aus diesem Grund betrachten wir unser kombiniertes F5- und NGINX-Portfolio als komplementär und nicht als Konkurrenz. Denn auf dem Gesamtmarkt für Anwendungsbereitstellung konkurriert man nicht mehr um die Platzierung an einem einzigen Standort, sondern um die Platzierung an mehreren Standorten.
Service-Meshes sind für die Skalierung und Sicherung von Containerumgebungen sowie für die Bereitstellung von Transparenz konzipiert. Da es sich um eine junge und sich rasch entwickelnde Technologie handelt, entstehen zahlreiche Modelle. Eines basiert auf der Verwendung eines Sidecar-Proxys ( Envoy hat sich als führendes CNCF- Projekt und als Sidecar-Proxy des Industriestandards etabliert) und das andere nutzt die Vorteile von Pro-App-Proxys, wie bei NGINX Plus .
Wir planen derzeit, beides zu unterstützen, da die Kunden sehr starke Vorstellungen hinsichtlich ihrer Infrastrukturauswahl haben, wenn es um Container geht. Einige bevorzugen Istio und Envoy, andere sind vollständig auf NGINX standardisiert.
Aufgrund der großen Anzahl an Komponenten, die in einer Containerumgebung betrieben und verwaltet werden müssen, ist vorhandenes Technologie-Know-how ein wichtiger Faktor bei der Auswahl eines Service Mesh. Organisationen, die NGINX als Standard für ihre Infrastruktur gewählt haben, tendieren wahrscheinlich eher zu einer NGINX-Service-Mesh-Lösung, da diese die gesamte NGINX-Software umfasst, vom NGINX-Proxy oder der NGINX-Einheit bis zum NGINX-Controller. Vorhandenes Betriebswissen zu NGINX und seinem Open-Source-Ökosystem kann zu weniger Reibungsverlusten und Verzögerungen bei der Bereitstellung führen.
Andere Organisationen vertreten die gleiche Meinung zu alternativen Open-Source-Lösungen wie Istio und Envoy. Aspen Mesh nutzt Envoy und implementiert auf Istio. Daher passt es besser zu Unternehmen, die bereits in die zugrunde liegende Technologie investiert haben. Es handelt sich um eine getestete, gehärtete, verpackte und geprüfte Distribution von Istio. Aspen Mesh fügt Istio mehrere Funktionen hinzu, darunter eine einfachere Benutzererfahrung durch das Aspen Mesh-Dashboard, ein Richtlinien-Framework, mit dem Benutzer Geschäftsziele festlegen, messen und durchsetzen können, sowie Tools wie Istio Vet und Traffic Claim Enforcer . Aspen Mesh lässt sich wie NGINX auch gut in F5 BIG-IP integrieren.
Sowohl NGINX als auch Aspen Mesh bieten Verwaltung und Visualisierung von Kubernetes-Clustern. Aspen Mesh und NGINX bieten ihre Lösung beide als Vor-Ort-Option an. Beide bieten Ablaufverfolgung und Metriken, die für die Lösung des Sichtbarkeitsproblems von entscheidender Bedeutung sind, einer der größten Produktionsherausforderungen, die von 37 % der Organisationen im State of Kubernetes Report von Replex genannt wurde.
Organisationen, die einen Sidecar-Proxy-basierten Ansatz für Service Mesh bevorzugen, werden Aspen Mesh bevorzugen. Organisationen, die der Ansicht sind, dass proxybasierte Service-Meshes pro App ihren Anforderungen am besten entsprechen, werden NGINX bevorzugen.
Ihre Wahl hängt von einer Reihe von Faktoren ab und wir glauben, dass dieser neue Bereich wichtig genug ist, um weiterhin Entscheidungen zu unterstützen, die unterschiedliche Kombinationen von Bedürfnissen und Anforderungen berücksichtigen.