Der Cloud-fähige ADC

Ein Cloud-fähiger Application Delivery Controller (ADC) ist kein herkömmlicher ADC. Er ist für die Bereitstellung auf kundenspezifischer oder COTS-Hardware verfügbar und ist eine skalierbare Softwarelösung, die sowohl den Bedarf an schneller, sicherer und verfügbarer Bereitstellung als auch Implementierung 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 Programmfunktionen kombiniert.

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

Ich habe bereits früher darüber geschrieben, was nötig ist, um als moderner App-Proxy zu gelten, und das ist sicherlich ein Teil dessen, was ein Cloud-fähiger ADC erfordert, aber die anspruchsvollen Umgebungen von heute erfordern mehr als nur technische Fähigkeiten; sie erfordern betriebliche und Ökosystemintegration und die Fähigkeit, moderne und aufkommende Anwendungsarchitekturen zu unterstützen.

Und ehrlich gesagt gibt es viele ADCs da draußen, die unter anderem dieselben Behauptungen hinsichtlich der Cloud-Bereitschaft und der Unterstützung sowohl traditioneller als auch neuer Anwendungsarchitekturen aufstellen. Heute möchte ich näher darauf eingehen, was einen Cloud-fähigen ADC von einem herkömmlichen ADC unterscheidet, bevor wir näher darauf eingehen, warum er in der heutigen Anwendungswelt so wichtig ist.

Fünf Grade der Differenzierung

Es gibt im Grunde fünf (sechs, wenn Sie es ganz genau nehmen wollen) verschiedene Möglichkeiten, wie sich ein Cloud-fähiger ADC von einem herkömmlichen ADC unterscheidet. Und da F5 schon lange vor meiner Zeit hier ziemlich genau definiert hat, was ein ADC sein sollte, verstehen wir den ADC besser als jeder andere. Sowohl was sie sein mussten als auch was sie weiterentwickeln müssen, um weiterhin Apps mit der Geschwindigkeit, Sicherheit und Stabilität bereitzustellen, die Unternehmen benötigen.

Leistung

Das ist doch ein Kinderspiel, oder? Denn wenn Sie Apps verwalten und als Proxy für diese fungieren, sollten Sie schnell (oder besser noch schneller) sein als die Apps, die Sie bereitstellen. Herkömmliche ADCs werden im Geräteformfaktor geliefert. Chassis, Hardware, Geräte. Herkömmliche ADCs sind jedoch immer noch durch die CPUs in der kundenspezifischen Hardware eingeschränkt, mit der sie arbeiten müssen. Da es sich bei ADCs um Plattformen handelt, liegt ihr Schwerpunkt eher auf der allgemeinen Geschwindigkeit, so wie sich Allzweck-CPUs auf die allgemeine Verarbeitung konzentrieren. Sie umfassen jedoch fast immer verschiedene Optionen zur Hardwarebeschleunigung, die vor der Bereitstellung ermittelt werden müssen. Wir sind vielleicht verrückt, aber wir glauben, dass ein Cloud-fähiger ADC in der Lage sein sollte, diese Einschränkung zu überwinden und zu verstehen, dass eine App einen Dienst mehr als eine andere benötigen könnte, während eine andere App einen anderen Dienst mehr als ein anderer benötigen könnte. Analog zur Idee der bedarfsgesteuerten Umwidmung von Rechenleistung, die dem gesamten Konzept des Cloud-Computing zugrunde liegt, sollten Unternehmen, die in Hardware jeglicher Art investieren, auch in der Lage sein, diese umzuwidmen.

Der Grund dafür, dass dies bei Diensten, die über dem Netzwerk angeordnet sind, wichtig ist, besteht darin, dass durch die Auslagerung allgemeiner Aufgaben auf bestimmte Hardware (FPGAs) die CPU für andere Aufgaben frei wird, z. B. Überprüfung, Änderung, Bereinigung von Anfragen und Antworten usw. Dadurch wird der gesamte „Stopp“ beim Proxy schneller, was wiederum geringere Latenzzeiten und zufriedenere Benutzer zur Folge hat.

Deshalb kann ein Cloud-fähiger ADC Barrieren durchbrechen, indem er die Vorteile softwaredefinierter Leistung nutzt und es Unternehmen ermöglicht, die Leistung des ADC für bestimmte Verarbeitungsarten, wie z. B. Sicherheit, programmgesteuert zu steigern. Das bedeutet, dass sich das Leistungsprofil der Hardware bei Bedarf ebenfalls ändern kann, wenn sich die Anforderungen der Organisation ändern. Das ist Agilität in der Hardware. Ich weiß, paradox, oder? Aber genau das gehört zu einem Cloud-fähigen ADC dazu: die Fähigkeit, spezialisierte Hardware umzufunktionieren, sodass Investitionen geschützt sind und die Notwendigkeit teurer, umfangreicher Upgrades entfällt.

Programmierbarkeit

Ein seit langem bestehender Frustfaktor, von dem ich persönlich immer wieder von Kunden gehört habe, ist die Uneinigkeit zwischen NetOps und DevOps, wenn es um Skriptfunktionen geht. Das Problem besteht darin, dass der herkömmliche ADC nur die grundlegendsten Skriptsprachen bietet und diese in Sprachen verfasst sind, die eher NetOps, nicht aber DevOps geläufig sind. Mittlerweile waren DevOps bereit, die Vorteile der Skripterstellung im Datenpfad zu erlernen, da sie eine Vielzahl agilerer Anforderungs-/Antwort-Routing- und Skalierungsstrategien sowie sogar Sicherheitsdienste ermöglichten. Doch da der herkömmliche ADC vorgelagert, also im Kernnetzwerk, angesiedelt ist, wollten die NetOps es den DevOps nicht überlassen, Skripte einzusetzen, die den Verkehrsfluss stören könnten.

Durch die Verfügbarkeit virtueller Editionen hatten DevOps nun Zugriff auf ihren eigenen, persönlichen, privaten ADC in Form einer virtuellen Maschine, mussten aber dennoch eine netzwerkbasierte Skriptsprache erlernen. Das ist nicht gut. Ein Cloud-fähiger ADC sollte sowohl NetOps im Kernnetzwerk als auch DevOps im App-Netzwerk, also in der Cloud, unterstützen. Und insbesondere DevOps und Entwickler bevorzugen entwicklerfreundlichere Sprachen wie node.js. Nicht nur, weil sie die Sprache kennen, sondern weil bereits ein umfangreiches Repository mit Bibliotheken (wie NPM ) und Diensten vorhanden ist, das eine schnellere Integration in eine entwicklerfreundliche Infrastruktur ermöglicht. Deshalb sollte ein Cloud-fähiger ADC beides unterstützen.

App-Sicherheit

Herkömmliche ADCs sorgen seit langem für grundlegende Anwendungssicherheit. Wenn man vor einer App sitzt, insbesondere vor einer Web-App, waren (und sind) sie normalerweise das Erste im Rechenzentrum, das einen Angriff erkennen und etwas dagegen unternehmen kann. Der Großteil dieser Sicherheit drehte sich verständlicherweise um Sicherheit auf Protokollebene. SYN-Flood-Schutz, DDoS-Erkennung und andere TCP- und grundlegende HTTP-bezogene Sicherheitsoptionen sind seit einiger Zeit fester Bestandteil herkömmlicher ADCs.

Aber ein Cloud-fähiger ADC sollte noch weiter gehen. Sie gehören wahrscheinlich zu den wenigen „Geräten“, die in die App-Architektur selbst integriert sind, um die unvermeidliche Skalierbarkeit zu gewährleisten, die heutige Anwendungen benötigen. Daher ist es nur sinnvoll, den Fokus gleichermaßen auf die Full-Stack-Sicherheit zu legen. Meinen wir zumindest, zumal es die Leistung steigert. Wenn Sie für eine Art der Verarbeitung eine Pause einlegen müssen, ist es sinnvoll, so viel wie möglich gleichzeitig zu erledigen. Dies ist effizienter und eliminiert die für die Übertragung von Box zu Box erforderliche Latenz. Wenn Sie schon einmal mit Kindern weite Strecken gereist sind, wissen Sie, wovon ich spreche. An der Tankstelle gibt es eine Toilette. Sie möchten doch nicht fünf Minuten später schon wieder an einer Raststätte anhalten, oder? Dasselbe gilt für die Sicherheit im Netzwerk. Tun Sie so viel wie möglich auf einmal, um den Mehraufwand zu vermeiden, der sowohl für Kunden als auch für das Unternehmen häufig eine Quelle der Frustration darstellt. Die Leistung ist entscheidend und ein Cloud-fähiger ADC sollte alles tun, um schnellere App-Erlebnisse zu gewährleisten.

Dies kann bedeuten, dass neue Modelle angeboten werden müssen, um der steigenden Nachfrage (und in manchen Fällen auch Anforderung) nach Unterstützung einer sicheren Kommunikation zwischen Mobilgeräten und Apps gerecht zu werden. Das bedeutet Unterstützung für Forward Secrecy (FS) und die Kryptografie, die dies ermöglicht. Dies bedeutet, neue Modelle zu ermöglichen, um die rechenintensive Verarbeitung der Ver- und Entschlüsselung auf die dafür vorgesehene Hardware auszulagern, ohne dabei die für die Unterstützung von Mikrodiensten und neuen Anwendungen erforderlichen Architekturen zu beschädigen. Ein Cloud-fähiger ADC sollte beides unterstützen, eine schnelle und sichere Kommunikation ermöglichen und sich gleichzeitig nahtlos in die heutigen Architekturen und Cloud-Umgebungen einfügen.

Partner-Ökosystem und Automatisierung

Die „Other API Economy“ ist von entscheidender Bedeutung für den Erfolg der Private Cloud und den Wettbewerbsvorteil, den Unternehmen durch eine zunehmende Automatisierung und Orchestrierung erlangen. Doch so schön es auch wäre: Im Rechenzentrum wird es immer eine Vielzahl von Diensten unterschiedlicher Anbieter geben, alle mit unterschiedlichen Integrations- und Objektmodellen. Das bedeutet oft eine mühsame, API-gesteuerte Automatisierung, die Fachwissen zu allen erforderlichen Komponenten erfordert. In Wirklichkeit sind zwei Integrationsebenen erforderlich, eine für die Orchestrierung und eine für die Automatisierung (nein, das ist nicht dasselbe) . Es gibt die inhärenten Automatisierungsfunktionen der Plattform über APIs und Vorlagen und dann gibt es die native Integration in das Partner-Ökosystem, bei der die Orchestrierung das Wichtigste ist. Beides ist für einen Cloud-fähigen ADC erforderlich. Ersterer gewährleistet die Automatisierung über proprietäre Produkte oder benutzerdefinierte Skripte und Frameworks wie Puppet und Chef, während letzterer die Orchestrierung über zunehmend wichtige Controller wie OpenStack, VMware und Cisco ermöglicht.

Ein Cloud-fähiger ADC sollte die verwendeten Frameworks und Systeme nativ integrieren und Orchestrierung über diese anbieten, um eine umfassende Orchestrierungslösung bereitzustellen.

Es muss nicht oft genug gesagt werden, dass ein Cloud-fähiger ADC Cloud-Vorlagen unterstützen sollte.

Das ist alles, was ich dazu sagen werde.

App-Modell

Herkömmliche ADCs entstanden aus der Notwendigkeit, einen robusten Satz von Diensten für herkömmliche Anwendungen anzubieten. Monolithen, wenn man so will. Die heutigen Anwendungen sind zunehmend verteilt, vielfältiger 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 weiterhin einige dieser Dienste. Und wenn mehrere Dienste gleichzeitig benötigt werden (wie etwa Lastverteilung und App-Sicherheit), ist ein ADC erforderlich. Während ein herkömmlicher ADC für Microservices möglicherweise nicht geeignet ist, ist ein Cloud-fähiger ADC dies. Dazu gehört eine größere Anzahl von Diensten, die von Lastausgleich und Sicherheit profitieren können, Dienste, die eindeutig in den Zuständigkeitsbereich von DevOps und nicht von Netops fallen, wie beispielsweise Memcached .

Obwohl es sich bei einem Cloud-fähigen ADC immer noch um eine Plattform handelt, unterstützt er dennoch die Programmierbarkeits-, Integrations- und Formfaktoranforderungen, die erforderlich sind, um die von traditionellen und neuen Apps benötigten Dienste in der von ihnen benötigten Umgebung bereitzustellen.

Es gibt viele Ähnlichkeiten zwischen einem herkömmlichen ADC und einem Cloud-fähigen ADC. Beide sind immer noch Plattformen, die mehrere Dienste mit einem gemeinsamen Betriebsmodell ermöglichen können. Beide sind programmierbar, lassen sich in andere Rechenzentrums- und Cloud-Systeme integrieren und sorgen für flexible Leistungsmöglichkeiten. Doch ein Cloud-fähiger ADC geht über das Traditionelle hinaus: Er unterstützt beides und ermöglicht zugleich die Zukunft von Geschäften und Anwendungen sowie deren zunehmend vielfältigem Bedarf an Integration und Interoperabilität mit einer großen Vielfalt an Infrastrukturen und Umgebungen.