Zusammen mit dem größeren Container-Ökosystem entwickeln sich auch Service Meshes stetig weiter und werden zunehmend ausgereifter. Allerdings stehen wir noch am Anfang, und es gibt verschiedene Ansätze, um das Problem der Verwaltung des Datenverkehrs zwischen Containern mithilfe von Service Meshes zu lösen.
Wir (damit ist das Unternehmen gemeint) mussten im Vorfeld unserer offiziellen Übernahme von NGINX in diesem Frühjahr viele Fragen beantworten. Einige davon drehten sich um technologische und lösungsbezogene „Überschneidungen“. Schließlich bieten sowohl NGINX als auch F5 Proxy-basierte Lösungen für die Anwendungsbereitstellung an. Außerdem entwickeln beide Unternehmen ein Service Mesh. Die Frage lautete: Welches würde sich durchsetzen?
Denn so läuft es bei Übernahmen häufig.
Wie mein Kollege von NGINX und ich immer wieder betonten, ergänzten sich die als überlappend bezeichneten Technologien unserer Einschätzung nach eher, als dass sie miteinander konkurrierten. Das gilt auch für unsere Service-Mesh-Lösungen.
Unsere Überlegungen beruhen auf einer gemeinsamen Vision der Anwendungsbereitstellung. Wir sind uns beide der Auswirkungen bewusst, die Container und die Cloud, Microservices und die Vielzahl an Sicherheitsverletzungen auf Architekturen und Modelle der Anwendungsbereitstellung haben. So wie es nicht mehr „den einen Datenpfad für die Bereitstellung aller Anwendungen“ gibt, gibt es auch nicht mehr „das eine Modell für die Bereitstellung aller Anwendungsdienste“. Die Cloud bringt mehrere Datenpfade mit sich. Container führen einen neuen Datenpfad ein. Beides erweitert die möglichen Platzierungen von Anwendungsdiensten: von einem netzwerkbasierten Proxy (einem ADC) bis hin zu einer langen Liste von Standorten, die vom Client über das Netzwerk, den Server und den Container bis zur Cloud reicht.
Wie wir in einem Beitrag über Architekturen aus unserer Reihe Bridging the Divide erläutert haben, hängt die Entscheidung, wo und wie Anwendungsdienste bereitgestellt werden, von vielen Faktoren ab. Es geht nicht nur um die Wahl zwischen Implementierungen verschiedener Anbieter oder „Enterprise-Lösungen und FOSS“, sondern auch um den Standort (Cloud oder On-Premises), das Betriebsmodell und sogar um die Abwägung zwischen einfacher Implementierung und benötigtem Funktionsumfang. Angesichts der Bandbreite des Bereitstellungspfads gibt es mehrere Möglichkeiten, Anwendungsdienste einzubinden.
Aus diesem Grund betrachten wir unser kombiniertes Portfolio aus F5 und NGINX als komplementär und nicht als konkurrierend. Denn auf dem Gesamtmarkt für die Anwendungsbereitstellung geht es nicht mehr um die Platzierung an einem einzigen Standort, sondern um die Platzierung an mehreren Standorten.
Service Meshes sind darauf ausgelegt, Containerumgebungen zu skalieren, abzusichern und Einblicke in sie zu ermöglichen. Da es sich um eine noch junge und sich schnell weiterentwickelnde Technologie handelt, entstehen derzeit verschiedene Modelle. Eines basiert auf der Verwendung eines Sidecar-Proxys (Envoy hat sich zu einem führenden CNCF-Projekt und zum branchenüblichen Sidecar-Proxy entwickelt), während das andere anwendungsspezifische Proxys nutzt, wie etwa NGINX Plus.
Derzeit planen wir, beide zu unterstützen, da Kunden bei Containern sehr klare Vorstellungen von der Wahl ihrer Infrastruktur haben. Einige bevorzugen Istio und Envoy, während andere vollständig auf NGINX standardisiert sind.
Die Anzahl der Komponenten, die in einer Container-Umgebung betrieben und verwaltet werden müssen, ist so groß, dass vorhandenes technologisches Fachwissen bei der Wahl eines Service Mesh eine wichtige Rolle spielt. Unternehmen, die ihre Infrastruktur auf NGINX standardisiert haben, tendieren naturgemäß eher zu einer NGINX-Service-Mesh-Lösung, da diese ausschließlich aus NGINX-Software besteht – vom NGINX-Proxy oder NGINX Unit bis hin zu NGINX Controller. Vorhandene Betriebserfahrung mit NGINX und seinem Open-Source-Ökosystem kann Reibungsverluste und Verzögerungen bei der Bereitstellung reduzieren.
Andere Unternehmen vertreten ähnliche Ansichten zu alternativen Open-Source-Lösungen wie Istio und Envoy. Aspen Mesh nutzt Envoy und baut auf Istio auf. Daher eignet es sich besonders für Unternehmen, die bereits in die zugrunde liegende Technologie investiert haben. Es handelt sich um eine getestete, gehärtete, paketierte und geprüfte Istio-Distribution. Aspen Mesh erweitert Istio um mehrere Funktionen, darunter eine einfachere Benutzererfahrung über 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 ebenso wie NGINX auch gut in F5 BIG-IP integrieren.
Sowohl NGINX als auch Aspen Mesh bieten Funktionen zur Verwaltung und Visualisierung von Kubernetes-Clustern. Beide Lösungen sind auch für den lokalen Betrieb verfügbar. Darüber hinaus stellen beide Tracing-Funktionen und Metriken bereit, die entscheidend sind, um mangelnde Transparenz zu beheben – eine der größten Herausforderungen im Produktivbetrieb, die von 37 % der Unternehmen im State of Kubernetes Report von Replex genannt wurde.
Unternehmen, die bei Service Meshes einen auf Sidecar-Proxys basierenden Ansatz bevorzugen, werden sich eher für Aspen Mesh entscheiden. Unternehmen, die der Ansicht sind, dass auf anwendungsspezifischen Proxys basierende Service Meshes ihren Anforderungen am besten entsprechen, werden eher NGINX bevorzugen.
Ihre Wahl hängt von einer Vielzahl von Faktoren ab. Wir halten diesen aufstrebenden Bereich für wichtig genug, um auch weiterhin verschiedene Optionen zu unterstützen, die unterschiedlichen Kombinationen von Bedürfnissen und Anforderungen gerecht werden.
Über den Autor
Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.
Weitere Blogbeiträge von Lori Mac VittieÄhnliche Blogbeiträge
F5 und Equinix bündeln ihre Kräfte, um die sichere Anwendungsbereitstellung in Multicloud-Umgebungen zu vereinfachen
F5 und Equinix ermöglichen es Unternehmen, sich weltweit sicher und zuverlässig mit ihren Partnern zu vernetzen.
API-Sicherheitsrisiken und -herausforderungen
Erfahren Sie, warum APIs für die moderne App-Entwicklung unverzichtbar sind und wie Sie sie vor den häufigsten Sicherheitslücken schützen. Profitieren Sie von Expertentipps und direkt umsetzbaren Strategien.
Ein Meilenstein für die Community Impact Grants von F5
F5 feiert das fünfjährige Bestehen seines innovativen Community Impact Grant-Programms, das gemeinnützige Organisationen, bei denen sich F5-Mitarbeitende ehrenamtlich engagieren, mit Fördermitteln in Höhe von 5.000 US-Dollar unterstützt.
Mit moderner, anpassungsfähiger und sicherer Gesundheits-IT Leben retten
Die IT-Investitionen im Gesundheitswesen tragen dazu bei, die schnellsten Wege zu einer besseren Versorgung zu finden, indem sie die medizinische Betreuung näher an die Patientinnen und Patienten bringen. Viele Gesundheitsunternehmen nutzen riesige Mengen an klinischen und anderen Gesundheitsdaten, um Entwicklungen zu verfolgen und übergreifende Trends in der gesamten Gesundheitslandschaft zu erkennen. Gleichzeitig nähern sie sich einer möglichst präzisen, individuell zugeschnittenen Versorgung an.
Verbesserung der Benutzer- und Administrationserfahrung durch sicheren hybriden Zugriff
Diese Kombination aus BIG-IP Access Policy Manager und Azure Active Directory ermöglicht Identitätsföderation, zentralisierten Benutzerzugriff (über Single Sign-on) und erhöhte Anwendungssicherheit (durch Multi-Faktor-Authentifizierung) für geschäftskritische Anwendungen sowie cloudbasierte und SaaS-Anwendungen. Dieser Ansatz vereinfacht die Einrichtung und Bereitstellung, reduziert den Verwaltungsaufwand und verbessert die gesamte Administration.
Das Internet der Sicherheitsdinge
Nein, das ist keine Tirade über die Sicherheit des IoT. Es ist eine Geschichte über Veränderung – genauer gesagt über Veränderung und ihre Auswirkungen auf die Sicherheit. Veränderung ist allgegenwärtig. Es gibt unzählige Axiome und Sprichwörter über Veränderung, also ist es ...