Der Cloud-fähige ADC

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Ein Cloud-fähiger Application Delivery Controller (ADC) ist kein herkömmlicher ADC. Er kann auf kundenspezifischer oder handelsüblicher Standardhardware (COTS) bereitgestellt werden und ist eine skalierbare Softwarelösung, die sowohl die schnelle, sichere und hochverfügbare Bereitstellung als auch das Deployment von Anwendungen unterstützt. Ein Cloud-fähiger ADC ermöglicht einen modernen, zweistufigen Ansatz für Rechenzentrumsarchitekturen, der traditionelle Stabilität, Sicherheit und Skalierbarkeit mit modernen, flexiblen, Cloud- und DevOps-freundlichen programmierbaren Funktionen verbindet.

Das ist eine schöne Beschreibung, aber was bedeutet das?

Ich habe bereits darüber geschrieben, welche Voraussetzungen erfüllt sein müssen, um als moderner App-Proxy zu gelten. Das gehört zweifellos zu den Anforderungen an einen cloudfähigen ADC. Doch die anspruchsvollen Umgebungen von heute erfordern mehr als nur technische Funktionen: Gefragt sind auch die Integration in Betriebsabläufe und Ökosysteme sowie die Fähigkeit, moderne und neu entstehende Anwendungsarchitekturen zu unterstützen.

Und ehrlich gesagt gibt es viele ADCs auf dem Markt, die ebenfalls für sich in Anspruch nehmen, cloudfähig zu sein und sowohl traditionelle als auch neue Anwendungsarchitekturen zu unterstützen. Daher möchte ich heute zunächst näher darauf eingehen, was einen cloudfähigen ADC von einem herkömmlichen ADC unterscheidet, bevor wir uns genauer damit befassen, warum er in der heutigen Anwendungswelt so wichtig ist.

Fünf Differenzierungsmerkmale

Im Wesentlichen gibt es fünf (sechs, wenn man es ganz genau nehmen will) Merkmale, durch die sich ein cloudfähiger ADC von einem herkömmlichen ADC unterscheidet. Und da F5 schon lange vor meiner Zeit praktisch definiert hat, was ein ADC sein sollte, verstehen wir ADCs wohl besser als jeder andere – sowohl was sie leisten mussten als auch wie sie sich weiterentwickeln müssen, damit Anwendungen weiterhin mit der Geschwindigkeit, Sicherheit und Stabilität bereitgestellt werden können, die Unternehmen benötigen.

Leistung

Das versteht sich doch von selbst, oder? Wenn Sie Anwendungen vorgeschaltet sind und als Proxy für sie fungieren, sollten Sie schließlich genauso schnell (oder besser noch: schneller) sein als die Anwendungen, die Sie bereitstellen. Herkömmliche ADCs werden als Appliances angeboten: Gehäuse, Hardware, Geräte. Dennoch sind herkömmliche ADCs durch die CPUs der kundenspezifischen Hardware eingeschränkt, mit der sie arbeiten müssen. Da ADCs Plattformen sind, lag ihr Schwerpunkt meist auf der allgemeinen Geschwindigkeit – ähnlich wie Allzweck-CPUs auf die allgemeine Verarbeitung ausgelegt sind. Sie umfassen jedoch fast immer verschiedene Optionen zur Hardwarebeschleunigung, die vor der Bereitstellung festgelegt werden müssen. Vielleicht klingt das verrückt, aber wir sind der Meinung, dass ein cloudfähiger ADC diese Einschränkung überwinden können sollte. Dabei muss er berücksichtigen, dass eine Anwendung einen bestimmten Dienst stärker benötigt als einen anderen, während bei einer anderen Anwendung wiederum ein anderer Dienst wichtiger sein kann. So wie die bedarfsgerechte Umwidmung von Rechenressourcen dem gesamten Konzept des Cloud Computing zugrunde liegt, sollten Unternehmen auch Hardwareinvestitionen jeder Art für andere Zwecke einsetzen können.

Der Grund, warum dies bei Diensten, die auf dem Netzwerk aufsetzen, so wichtig ist: Durch die Auslagerung gängiger Aufgaben auf spezielle Hardware (FPGAs) wird die CPU für andere Aufgaben frei, etwa für die Prüfung, Änderung und Bereinigung von Anfragen und Antworten. Dadurch wird der gesamte „Zwischenstopp“ am Proxy schneller, was zu geringerer Latenz und zufriedeneren Benutzern führt.

Deshalb kann ein Cloud-fähiger ADC Grenzen überwinden, indem er softwaredefinierte Leistung nutzt und es Unternehmen ermöglicht, die Leistung des ADC für bestimmte Verarbeitungsarten, etwa Sicherheitsaufgaben, programmgesteuert zu erhöhen. Ändern sich die Anforderungen des Unternehmens, lässt sich somit auch das Leistungsprofil dieser Hardware bei Bedarf entsprechend anpassen. Das ist Agilität in Hardware. Klingt paradox, nicht wahr? Doch genau das zeichnet einen Cloud-fähigen ADC aus: Spezialisierte Hardware kann für andere Zwecke eingesetzt werden, sodass Investitionen geschützt sind und teure Komplettaustausche vermieden werden können.

Programmierbarkeit

Eine seit Langem bestehende Frustration, von der ich persönlich immer wieder von Kunden gehört habe, ist die Uneinigkeit zwischen NetOps und DevOps hinsichtlich der Skripting-Möglichkeiten. Das Problem besteht darin, dass herkömmliche ADCs nur sehr grundlegende Skripting-Funktionen bieten – und das in Sprachen, mit denen NetOps besser vertraut ist als DevOps. DevOps war durchaus bereit, sich einzuarbeiten, um die Vorteile des Skriptings im Datenpfad zu nutzen, da es vielfältige Möglichkeiten für ein agileres Request-/Response-Routing, Skalierungsstrategien und sogar Sicherheitsdienste eröffnet. Da der herkömmliche ADC jedoch vorgelagert im Kernnetzwerk angesiedelt war, kam es für NetOps nicht infrage, DevOps Skripte bereitstellen zu lassen, die den Datenverkehr beeinträchtigen könnten.

Durch die Verfügbarkeit virtueller Editionen hatten DevOps nun Zugriff auf einen eigenen, persönlichen und privaten ADC in Form einer virtuellen Maschine, waren aber weiterhin gezwungen, eine netzwerkspezifische Skriptsprache zu erlernen. Das ist nicht gut. Ein cloudfähiger ADC sollte sowohl NetOps im Kernnetzwerk als auch DevOps im Anwendungsnetzwerk, etwa in der Cloud, unterstützen. Und insbesondere DevOps und Entwickler bevorzugen entwicklerfreundlichere Sprachen wie node.js. Nicht nur, weil sie die Sprache beherrschen, sondern auch, weil bereits ein umfangreiches Angebot an Bibliotheken (wie NPM) und Diensten vorhanden ist, das eine schnellere Integration in entwicklerfreundliche Infrastrukturen ermöglicht. Deshalb sollte ein cloudfähiger ADC beide unterstützen.

App-Sicherheit

Traditionelle ADCs sorgen seit Langem für eine grundlegende Anwendungssicherheit. Da sie einer Anwendung – insbesondere Webanwendungen – vorgeschaltet sind, waren (und sind) sie in der Regel die erste Instanz im Rechenzentrum, die einen Angriff erkennen und entsprechende Maßnahmen ergreifen kann. Der Großteil dieser Sicherheitsfunktionen konzentrierte sich verständlicherweise auf die Protokollebene. Schutz vor SYN-Flood-Angriffen, DDoS-Erkennung und andere Sicherheitsoptionen für TCP und grundlegendes HTTP gehören bereits seit geraumer Zeit zum festen Funktionsumfang traditioneller ADCs.

Doch ein cloudfähiger ADC sollte noch weiter gehen. Er ist wahrscheinlich eines der wenigen „Geräte“, die direkt in die Anwendungsarchitektur integriert sind, um die für heutige Anwendungen unvermeidliche Skalierung zu gewährleisten. Daher ist es nur sinnvoll, den gleichen Fokus auf die Sicherheit des gesamten Stacks zu legen. Zumindest sind wir dieser Meinung – insbesondere, weil dies auch die Performance verbessert. Wenn für eine bestimmte Verarbeitung ohnehin ein Zwischenstopp erforderlich ist, bietet es sich an, gleichzeitig so viel wie möglich zu erledigen. Das ist effizienter und vermeidet die Latenz, die beim Durchlaufen mehrerer Geräte entsteht. Wenn Sie schon einmal mit Kindern eine längere Strecke gefahren sind, wissen Sie, was gemeint ist. An der Tankstelle gibt es eine Toilette. Sie möchten doch nicht fünf Minuten später schon wieder an einem Rastplatz anhalten, oder? Genauso verhält es sich mit der Sicherheit im Netzwerk. Erledigen Sie möglichst viel auf einmal, um den zusätzlichen Aufwand zu vermeiden, der sowohl bei Kunden als auch im Unternehmen häufig für Frustration sorgt. Performance ist entscheidend, und ein cloudfähiger ADC sollte alles daransetzen, schnellere Anwendungserlebnisse zu ermöglichen.

Das kann bedeuten, neue Modelle für die Bewältigung der steigenden Nachfrage (und in einigen Fällen der Anforderung) nach sicherer Kommunikation zwischen Mobilgeräten und Anwendungen anzubieten. Dazu gehört die Unterstützung von Forward Secrecy (FS) und der dafür erforderlichen Kryptografie. Ebenso müssen neue Modelle ermöglicht werden, mit denen sich die rechenintensive Ver- und Entschlüsselung auf speziell dafür ausgelegte Hardware auslagern lässt, ohne die für Microservices und neue Anwendungen erforderlichen Architekturen zu beeinträchtigen. Ein cloudfähiger ADC sollte beides unterstützen und sowohl eine schnelle als auch sichere Kommunikation ermöglichen, während er sich nahtlos in heutige Architekturen und Cloud-Umgebungen einfügt.

Partner-Ökosystem und Automatisierung

Die andere API-Ökonomie ist entscheidend für den Erfolg der Private Cloud und für den Wettbewerbsvorteil, den Unternehmen durch einen höheren Automatisierungs- und Orchestrierungsgrad erzielen. Doch so wünschenswert es auch wäre: Im Rechenzentrum wird es immer eine Vielzahl von Diensten unterschiedlicher Anbieter geben, die jeweils eigene Integrations- und Objektmodelle verwenden. Das führt häufig zu einer aufwendigen API-gesteuerten Automatisierung, die Fachwissen zu jeder benötigten Komponente voraussetzt. Tatsächlich sind zwei Integrationsebenen erforderlich: eine für die Orchestrierung und eine für die Automatisierung (nein, das ist nicht dasselbe). Zum einen gibt es die integrierten Automatisierungsfunktionen der Plattform, die über APIs und Vorlagen bereitgestellt werden, und zum anderen die native Integration in das Partner-Ökosystem, in dem die Orchestrierung im Mittelpunkt steht. Ein cloudfähiger ADC benötigt beides. Ersteres ermöglicht die Automatisierung über proprietäre Produkte oder benutzerdefinierte Skripte und Frameworks wie Puppet und Chef, während Letzteres die Orchestrierung über zunehmend wichtige Controller wie OpenStack, VMware und Cisco ermöglicht.

Ein Cloud-fähiger ADC sollte sich nativ integrieren lassen und über die Frameworks und Systeme, die zur Bereitstellung einer umfassenden Orchestrierungslösung eingesetzt werden, Orchestrierungsfunktionen bieten.

Es sollte nicht mehr als einmal gesagt werden müssen, dass ein cloudfähiger ADC Cloud-Vorlagen unterstützen sollte.

Damit ist dazu alles gesagt.

App-Modell

Herkömmliche ADCs entstanden aus dem Bedarf heraus, einen robusten Satz von Diensten für traditionelle Anwendungen bereitzustellen – für monolithische Anwendungen sozusagen. Heutige Anwendungen sind zunehmend verteilt, vielfältig und anders als ihre traditionellen Vorgänger und nutzen eine Vielzahl von Architekturen, Plattformen und Bereitstellungsmodellen. Ob Container oder virtuelle Maschinen, Cloud- oder Cloud-ähnliche Umgebungen: Anwendungen benötigen nach wie vor einige dieser Dienste. Und wenn mehrere Dienste gleichzeitig benötigt werden (beispielsweise Lastausgleich und Anwendungssicherheit), ist ein ADC gefragt. Ein herkömmlicher ADC ist für Microservices möglicherweise nicht geeignet, ein Cloud-fähiger ADC hingegen schon. Dazu gehört ein breiteres Spektrum an Diensten, die von Lastausgleich und Sicherheit profitieren können – Dienste, die eindeutig in den Zuständigkeitsbereich von DevOps und nicht von NetOps fallen, wie etwa memcached.

Ein cloudfähiger ADC ist zwar nach wie vor eine Plattform, erfüllt jedoch die Anforderungen an Programmierbarkeit, Integration und Formfaktor, die notwendig sind, um sowohl traditionellen als auch neuartigen Anwendungen die benötigten Dienste in der jeweils erforderlichen Umgebung bereitzustellen.

Ein herkömmlicher ADC und ein Cloud-fähiger ADC weisen viele Gemeinsamkeiten auf. Beide sind Plattformen, die mehrere Dienste mit einem einheitlichen Betriebsmodell ermöglichen. Beide sind programmierbar, lassen sich in andere Rechenzentrums- und Cloud-Systeme integrieren und bieten flexible Leistungsmerkmale. Ein Cloud-fähiger ADC geht jedoch über herkömmliche Lösungen hinaus: Er unterstützt sowohl traditionelle als auch neue Anwendungen und schafft zugleich die Voraussetzungen für die Zukunft von Unternehmen und Anwendungen sowie deren zunehmend vielfältigen Bedarf, sich in unterschiedlichste Infrastrukturen und Umgebungen zu integrieren und mit ihnen zusammenzuarbeiten.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

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