Skalierbarkeit ist sowohl für Unternehmen als auch für Anwendungen eine entscheidende Fähigkeit. Auf der Geschäftsseite ist die Skalierung von Vorgängen der Schlüssel zur Ermöglichung der neuen App-Ökonomie und ihres nahezu konstanten Zustands hektischer Bereitstellung. Auf der Anwendungsseite unterstützen wir durch Skalierbarkeit das Wachstum sowohl bei Privat- als auch bei Unternehmenskunden und gewährleisten für beide erstklassige Leistung und Verfügbarkeit.
Im Mittelpunkt der Skalierbarkeit steht der Lastausgleich. Seit Mitte der 1990er Jahre ist Lastenausgleich die Methode, mit der wir Anwendungen skalieren, indem wir die Arbeitslast auf immer größere Farmen aus Servern, Netzwerken, Anwendungen und Diensten verteilen.
Früher drehte sich beim Lastausgleich alles um das Netzwerk. Aufbauend auf vorhandenen Techniken und Protokollen zur Skalierung von Netzwerken konzentrierte sich der Lastenausgleich auf jene Aspekte der Client-Server-Kommunikation, die zur Verteilung der Arbeitslast genutzt werden konnten. Plain Old Load Balancing (POLB) war geboren.
Es hat funktioniert, und zwar gut. Ohne POLB ist es nahezu unmöglich zu sagen, ob das Web, wie wir es kennen, zustande gekommen wäre. Es war und ist noch immer von entscheidender Bedeutung, um die Unternehmens- und Verbraucherbevölkerung von heute zu unterstützen und auch die von morgen unterstützen zu können.
Irgendwann in den frühen 2000er Jahren wurde der Load Balancer aufgrund seiner strategischen Lage zur perfekten Plattform für die Erweiterung um weitere, das Anwendungserlebnis verbessernde Funktionen. Schließlich wurden Anwendungsbeschleunigung, Optimierung, Caching und Komprimierung hinzugefügt. Auch die Sicherheit würde ihren Weg auf diese gleiche Plattform finden, ihre Position im Netzwerk wäre zu perfekt, um sie zu ignorieren. Als Gatekeeper für Anwendungen verfügt er über die Fähigkeit, den Anwendungsverkehr zu prüfen, zu extrahieren, zu ändern und zu transformieren, und erhält dadurch einzigartige Einblicke, die sowohl für die Sicherheit als auch für die Leistung gelten.
Irgendwann in den frühen 2000er Jahren gingen wir über POLB hinaus und machten etwas anderes. Aus Load Balancern wurden Anwendungsbereitstellungsplattformen, die ebenso sichere, schnelle und verfügbare Apps bereitstellen konnten wie deren bloße Skalierung mit POLB.
Der ADC (Application Delivery Controller), wie diese modernen Plattformen genannt werden, kann nicht nur POLB-Funktionen anbieten, sondern ein wahres Füllhorn an Funktionen, die ihn für die Leute von unschätzbarem Wert machen, die heute nicht nur mit der Bereitstellung von Apps, sondern auch mit deren Auslieferung beauftragt sind.
Zunehmend sind dabei nicht die Netzwerkteams, sondern Architekten und Betriebsmitarbeiter betroffen.
Dieser Wandel wurde durch eine Reihe von Technologien vorangetrieben, die im letzten Jahrzehnt entstanden sind. Von Agile über Cloud und DevOps bis hin zu Mobilgeräten: Durch bewährte Methoden werden heute einige Anwendungsdienste aus dem Netzwerk in den Bereich der Anwendungen verlagert.
Und während die Verantwortung für die Skalierbarkeit vom Netzwerk auf die Architekten und den Betrieb verlagert wird, wird der ADC so eingesetzt, als sei er in den 1990er Jahren steckengeblieben. Wenn es als POLB behandelt wird, bleibt der Großteil des Mehrwerts, den es Architekten und Betreibern hinsichtlich der Verbesserung von Leistung und Sicherheit bietet, auf der Strecke (oder besser gesagt: auf der Strecke).
Dies liegt normalerweise daran, dass die Architekten und Betriebsteams, die jetzt für die Skalierung der Anwendungen verantwortlich sind, nicht genau wissen, was ein ADC für sie und – was noch wichtiger ist – für ihre Apps und Architekturen tun kann. Es ist Zeit, dass wir das ändern und über POLB hinausgehen.
Das Ziel von POLB war einfach: Verfügbarkeit. Ob dies durch die Implementierung einer auf Redundanz basierenden HA-Architektur (High Availability) oder durch die Verwendung einer N+1-Skalierungsarchitektur geschah, das Ziel war dasselbe: die Website (oder App) unter allen Umständen verfügbar zu halten.
Auch heute lautet das Ziel Verfügbarkeit, allerdings gepaart mit Effizienz und Agilität. Alle drei sind Schlüsselmerkmale moderner Unternehmen und der Architekturen, die ihre kritischen Anwendungen unterstützen. Um dieses Ziel zu erreichen, müssen wir allerdings über POLB hinausgehen und in eine Welt der Anwendungsweiterleitung und Lastverteilung vordringen, die diese entscheidenden Effizienzsteigerungen sowohl in die Anwendungsarchitekturen als auch in die Infrastruktur bringt. Diese Funktionen basieren auf Schicht 7 des Netzwerkstapels – der Anwendungsschicht – und in modernen Architekturen bedeutet dies HTTP.
L7 LB-Proxys können nicht nur die Last basierend auf Anwendungsvariablen wie Verbindungslast, Antwortzeiten und Anwendungsstatus verteilen, sondern auch die Verteilung (Weiterleitung) basierend auf URLs, HTTP-Headern und sogar Daten in HTTP-Nachrichten durchführen.
L7-Load Balancer sind heute in der Lage, diese verschiedenen Arten von Anwendungsschichtdaten zu analysieren, zu extrahieren und darauf zu reagieren. Sie können auf vielfältige Weise an Anwendungen und Microservice-Architekturen teilnehmen und diese erweitern, unter anderem durch:
Da ein L7 LB logisch vor den Anwendungen positioniert ist, die er bedient, hat er Einblick in jede einzelne Anfrage – und Antwort. Dies bedeutet, dass es in der Lage ist, eine Reihe von Prüfungen und Abwägungen an den Anfragen vorzunehmen, bevor diese zur gewünschten Anwendung weitergeleitet werden können. Diese Kontrollen und Ausgleiche sind von entscheidender Bedeutung, um sicherzustellen, dass bösartiger Datenverkehr erkannt und abgelehnt wird, und um zu verhindern, dass seine negativen Auswirkungen die Stabilität, Verfügbarkeit und Integrität von Back-End-Anwendungen beeinträchtigen.
Dabei geht es jedoch nicht nur darum, schädlichen Datenverkehr davon abzuhalten, die Server zu erreichen. Es geht auch darum, böswillige Akteure zu stoppen. Das bedeutet, dass wir in der Lage sein müssen, sie zu identifizieren – und zwar nicht nur diejenigen ohne gültige Zugangsdaten, sondern auch diejenigen, die Zugangsdaten verwenden, die ihnen gar nicht gehören. Die Bedeutung der Zugriffskontrolle hat aufgrund der steigenden Zahl von Sicherheitsverletzungen aufgrund gestohlener Zugangsdaten zugenommen. Durch die Cloud ist es außerdem erneut dringend erforderlich geworden, Anmeldeinformationen global und anwendungsübergreifend zu verwalten. So soll das potenzielle Risiko durch verwaiste Konten und Testkonten verringert werden, die Zugriff auf in SaaS-basierten Anwendungen gespeicherte Unternehmensdaten gewähren. Die Identitätsföderation ist mittlerweile mehr als nur eine Strategie zur Produktivitätssteigerung; sie ist zu einer Schlüsseltaktik in der gesamten Sicherheitsstrategie des Unternehmens geworden.
Zu den Funktionen, die einem L7 LB hinzugefügt werden können, gehören sowohl Funktionen zur Analyse des Verhaltens und der Identität von Clients als auch des tatsächlichen Inhalts von Nachrichten, die zwischen Clients und Backend-Diensten ausgetauscht werden. Dadurch kann das L7 LB unter anderem folgende Funktionen ausführen:
Die Leistung ist eine entscheidende Komponente für den Anwendungserfolg und damit auch für den Geschäftserfolg. Früher haben Unternehmen vor den Anwendungen mehrere Lösungen zur Anwendungsbeschleunigung implementiert, um den Bereitstellungsprozess zu beschleunigen. ADCs haben diese gleichen Lösungen als optionale (Add-On-)Komponenten eingebaut, diese Funktionen letztendlich jedoch direkt als Teil der Kernfunktionen zum Lastausgleich integriert; ein Ausdruck der Bedeutung der Leistung für den Hauptfokus auf die Bereitstellung von Anwendungen und Diensten.
Daher verfügt das L7 LB über zahlreiche Merkmale und Funktionen, deren Schwerpunkt auf der Leistungssteigerung liegt. Einige dieser Funktionen – insbesondere jene, die auf an den Client zurückgesendete App-Antworten reagieren – sind auf den Inhalt ausgerichtet. Viele davon sind grundlegende Entwicklertechniken, mit denen Inhalte verkleinert werden, während andere darauf abzielen, die Anzahl der erforderlichen Roundtrips zwischen Client und Server zu verringern.
Außerdem muss beachtet werden, dass L7-Proxys nicht nur auf die Optimierung von Inhalten ausgerichtet sind, sondern auch wichtige Enabler für leistungsorientierte Architekturen sind, die Techniken zum Datenbank-Lastausgleich sowie die Integration von In-Memory-Caches (wie Memcached) umfassen, um die allgemeine Anwendungsleistung zu verbessern. Die L7-Proxys, die sich für die Aktivierung dieser Architekturen gut eignen, verfügen im Allgemeinen über eine Datenpfad-Skriptsprache , die eine individuelle Anpassung der Verteilung und des Routings ermöglicht.
Bei anderen Funktionen liegt der Schwerpunkt auf der Reduzierung des Overheads auf Backend-Servern, um die Leistung zu verbessern, sowie auf der Möglichkeit, die Last basierend auf Leistungsschwellenwerten zu verteilen.
Zu den optimierenden Funktionen und Fähigkeiten eines L7 LB gehören:
Clientseitig (Response-Optimierung) |
Backend-Serverseite |
• Minimierung • HTTP-Komprimierung • Pufferung • Skriptaggregation • SSL-Offload |
• TCP-Multiplexing • Zwischenspeicherung • Leistungsbasierte Lastverteilung • Automatische Skalierbarkeit |
Wenn eine Infrastruktur stärker in die Anwendungsarchitektur integriert werden soll, muss sie unbedingt in die CI/CD-Pipeline integrierbar sein. Das bedeutet, dass wir moderne DevOps- und Agile-bezogene Methoden sowie die Tool-Sets unterstützen, die die Ausführung automatisierter Release- und Bereitstellungsstrategien ermöglichen.
Zu diesem Zweck muss L7 LB nicht nur APIs für die Verwaltung bereitstellen, sondern auch Mittel für die Überwachung und Bereitstellung, um sicherzustellen, dass kontinuierliches Feedback und kontinuierliche Bereitstellung möglich sind, um die anspruchsvollen Zeitpläne und Budgets von heute einzuhalten.
F5 unterstützt eine Vielzahl programmgesteuerter Optionen für die Bereitstellung, Implementierung, Verwaltung und Überwachung der L7 LB-Infrastruktur, darunter:
Es gibt verschiedene Gründe, warum die Verantwortung für Anwendungsinfrastrukturen wie POLB und L7 LB von den Netzwerkteams auf die Anwendungs- und Betriebsteams verlagert wird. Unabhängig davon, ob es sich um die Einführung von Agile oder DevOps als Reaktion auf die geschäftliche Nachfrage nach mehr Apps mit kürzeren Bereitstellungszeiten oder die Notwendigkeit einer schnelleren Skalierung als je zuvor handelt: Über POLB hinausgehende Lösungen bieten eine größere Auswahl an Optionen für Sicherheit, Leistung und Verfügbarkeit, die zur Unterstützung moderner App- und Bereitstellungsarchitekturen auf einer einzigen, verwaltbaren und programmierbaren Plattform erforderlich sind, die in die moderne CI/CD-Pipeline passt.
Es ist an der Zeit, über POLB hinauszugehen und die Infrastruktur zu nutzen, die zunehmend in Ihren Bereich fällt.