Oder sind es etwa „Tränen“ der Frustration? ¯\_(ツ)_/¯ Vielleicht ist es ja beides.
Zwischen Netzwerk- und Anwendungsarchitekturen besteht ein Zusammenhang. In der Regel sprechen wir gerne darüber, wie sich Änderungen und Verschiebungen in Anwendungsarchitekturen auf das Netzwerk auswirken – sowohl im Hinblick auf Lösungen als auch auf dessen Architektur. Doch auch das Gegenteil trifft zu: Die Architektur und das Verhalten des Netzwerks können erhebliche Auswirkungen auf Anwendungen und deren Architektur haben.
So ist einer der Gründe dafür, dass wir die Aufspaltung monolithischer Anwendungen in zahlreiche Microservices heute und nicht schon zu Zeiten von SOA erleben, das Netzwerk. Genauer gesagt: die Geschwindigkeit des Netzwerks. Zu Zeiten von SOA gab es durch die Beschaffenheit von Netzwerken (und die Gesetze der Physik) bedingte Einschränkungen, die es unmöglich machten, eine einzige Antwort aus mehr als drei oder vier Services zusammenzusetzen. Nun ja, nicht unmöglich, aber aufgrund der durch jeden Aufruf verursachten Latenz unerwünscht.
Heute verfügen wir über schnellere Netzwerke mit höherer Bandbreite und eine um eine Größenordnung höhere Rechenleistung, die eine solche Aufteilung überhaupt erst praktikabel machen. Zusätzlich erleichtert wird sie durch die Beschaffenheit der Container, die so häufig mit Microservices kombiniert werden wie Kaffee mit Donuts. Da „das Netzwerk“ zwischen zwei Diensten, die miteinander kommunizieren müssen, oft ein virtuelles Konstrukt ist (die Pakete verlassen den Hostserver nie wirklich und sind daher nicht von der Latenz betroffen, die bei der Übertragung über eine physische Netzwerkverbindung entsteht), können zur Beantwortung einer einzelnen Anfrage wesentlich mehr Dienste aufgerufen werden, als dies zu Zeiten von SOA realistischerweise möglich war.
Das bedeutet jedoch nicht, dass wir außer Acht lassen sollten, wie viele Verbindungen und Zwischenstationen durchlaufen werden müssen, um auf eine Anfrage zu antworten, oder welchen Einfluss die Architektur auf die Anwendungsleistung hat. Denn auch wenn die Rechenleistung höher und die Leitungen leistungsfähiger sind, müssen wir uns nach wie vor mit betrieblichem Overhead auseinandersetzen. Und dieser beeinträchtigt weiterhin die Leistung. Eine der einfachsten Möglichkeiten, den betrieblichen Overhead zu reduzieren (und die Leistung zu verbessern), besteht darin, die Komplexität durch das Entfernen (unnötiger) Schichten aus einer Architektur zu verringern.
Komplexität von Container-Umgebungen reduzieren
Bei den meisten Container-Bereitstellungen kommt innerhalb des Clusters eine Art Load Balancer zum Einsatz, um die Skalierung von Microservices und Anwendungen in der Container-Umgebung zu steuern. Das liegt daran, dass diese häufig für das L7-Routing von APIs (also die Ingress-Steuerung) zuständig sind, während native Load-Balancing-Konstrukte auf iptables basieren, das natürlich kein HTTP versteht – die Sprache des L7-Routings. Daher gibt es innerhalb des Container-Clusters eine ganze Reihe von L7-Load-Balancern.
Die meisten Bereitstellungen benötigen außerdem einen Lastenausgleich außerhalb des Clusters, um externen Datenverkehr an den richtigen Load Balancer innerhalb des Clusters weiterzuleiten. Dazu verwenden sie herkömmlichen Lastenausgleich und verteilen die Anfragen so an den richtigen Load Balancer innerhalb des Clusters.
Wir nennen den Load Balancer außerhalb des Clusters BIG-IP und den innerhalb des Clusters den internen Load Balancer. Weil es mein Blog ist, deshalb.
Das Problem besteht darin, dass die Anzahl der internen Load-Balancer-Instanzen schwankt (manchmal erheblich). Bei jeder Änderung muss BIG-IP darüber informiert werden. Traditionell erfolgte dies manuell: Der BIG-IP-Verantwortliche musste den Pool von Hand anpassen. Das ist frustrierend für Entwickler und DevOps und mühsam für NetOps. Mit anderen Worten: Niemand möchte es auf diese Weise machen.
Deshalb gibt es Lösungen wie den F5 Container Connector . F5 Container Connector ist ein container-nativer Dienst, der sich in den Container-Orchestrator integriert und die Umgebung überwacht. Wenn sich eine Änderung auf einen internen Load Balancer auswirkt, wird ein Prozess zur Aktualisierung von BIG-IP ausgelöst. Das bedeutet, dass BIG-IP bei schwankender Nachfrage automatisch auf dem neuesten Stand gehalten wird und Anfragen angemessen an einen aktiven, fehlerfrei funktionierenden internen Load Balancer verteilen kann. Eine manuelle Anpassung ist nicht erforderlich.
Diese zweistufige Skalierungsarchitektur bietet den Vorteil eines praktischen Eingangspunkts (BIG-IP), an dem SSL/TLS terminiert werden kann, was zu messbaren Leistungsverbesserungen führt. Sehr schön.
Aber warum hier aufhören? BIG-IP kann L7-Routing bereitstellen. Wenn Sie die Dienste von F5 Container Connector nutzen, können Sie weitere Leistungssteigerungen erzielen (und den Betriebsaufwand senken), indem Sie den internen Load Balancer vollständig eliminieren. Wirklich. BIG-IP kann als Ingress-Controller für Kubernetes und Red Hat OpenShift fungieren.
Indem Sie die Ingress-Verantwortung auf BIG-IP verlagern, eliminieren Sie eine komplette Skalierungsebene (den internen Load Balancer) und verbessern dadurch unmittelbar die Performance. Da der externe Load Balancer ein F5 BIG-IP ist, können Sie zusätzlich sicherheitsorientierte Anwendungsdienste wie eine fortschrittliche WAF mit Bot-Abwehr direkt am Kontaktpunkt bereitstellen, anstatt innerhalb des Container-Clusters (oder überhaupt nicht).
Kampf der Ops-Clans
Da Container immer häufiger in die Produktion überführt werden (und das werden sie), wird eine engere Zusammenarbeit zwischen DevOps und NetOps erforderlich sein, um derartige Verbesserungen umzusetzen und Skalierbarkeit, Geschwindigkeit und Sicherheit von Anwendungen zu gewährleisten. Schließlich geht es nicht nur darum, Schaltflächen zu betätigen und Self-Service-Pipelines zu nutzen. Die Architektur ist eine entscheidende Komponente, die unter Einbeziehung von DevOps und NetOps konzipiert werden muss, damit wir keine Möglichkeiten außer Acht lassen, beispielsweise die Anwendungsleistung zu verbessern.
Denn Anwendungsperformance ist Teamsache. Sie wird durch den Code (AppDev), die Plattform, auf der der Code bereitgestellt wird (DevOps), die Netzwerkarchitektur sowie die Anwendungsdienste beeinflusst, die zur Absicherung und Skalierung der Anwendung eingesetzt werden (NetOps). Die Architektur zu optimieren, indem nach Möglichkeit Ebenen entfallen, ist sowohl aus betrieblicher als auch aus geschäftlicher Sicht sinnvoll. Dafür müssen jedoch alle Teammitglieder mitwirken.
Also bestellt Pizza und Bier, bringt DevOps und NetOps an einen Tisch und kommt ins Gespräch. Findet heraus, ob auch ihr die Anwendungsleistung verbessern könnt, indem ihr unnötige Schichten in eurer Container-Umgebung beseitigt.
Ü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 ...