Wo F5 in eine DevOps-Welt passt
Nach meinen Vorträgen auf Konferenzen werde ich oft gefragt, was Hund F5 im Rennen hat. In letzter Zeit handelt es sich bei diesem Thema normalerweise um DevOps oder es ist in irgendeiner Weise mit DevOps verbunden.
Die Realität besteht darin, dass anwendungsaffine Dienste wie der Lastenausgleich in Richtung der Anwendungen verlagert werden , in die agilere, softwaregesteuerte und automatisierte Umgebung, die das Anwendungsnetzwerk ausmacht. Dort werden rechen- und anwendungszentrierte Systeme wie Caches (denken Sie an Memcached und Redis) sowie Datenbanken und Container mithilfe von CI/CD-Methoden (Continuous Integration/Continuous Delivery) eingesetzt, die auf einem hohen Maß an Automatisierung und Orchestrierung basieren.
F5 – und insbesondere BIG-IP – ist fast gleichbedeutend mit Lastausgleich. Wir machen das schon seit vor der Jahrhundertwende und viele der grundlegenden Algorithmen und Konzepte zum Lastenausgleich, die Sie heute mit anderen Lastenausgleichsmodulen verwenden, wurden tatsächlich hier erfunden. Daher wäre es eine Untertreibung zu sagen, dass wir uns mit Lastausgleichsanwendungen auskennen. Und wir tun dies mit Software, die entweder auf speziell angefertigter Hardware oder sogar in der Cloud bereitgestellt wird.
Diese Software wird mit einer API aktiviert. Sie heißt iControl und ist für Ihren Programmierkomfort sowohl in den Varianten SOAP als auch REST verfügbar. Mit dieser API kann jeder (sogar ich) die Lastausgleichsdienste (und andere Dienste) eines BIG-IP für jede Anwendung bereitstellen, konfigurieren und steuern.
Wie ich bereits sagte, verschieben sich anwendungsaffine Dienste jeden Tag mehr in Richtung Anwendung. Skalierbarkeit – Lastausgleich – ist einer dieser Dienste. Heutzutage handelt es sich um eine kritische Komponente für jede Anwendung und zunehmend auch für die Microservices, aus denen moderne Anwendungen bestehen. Wie Microsoft in einem Dokument zur Skalierung von Diensten aus dem Jahr 2015 hervorhebt:
Angesichts der Vielzahl unterschiedlicher Maschinen muss sich der Entwickler Gedanken über die Partitionierung der Anwendungsarbeitslast sowie über die zur Unterstützung der einzelnen Partitionierungsschemata erforderliche Netzwerkkonnektivität machen. Ein sehr wichtiger Aspekt der Konnektivität besteht zwischen externen Benutzern und dem Dienst selbst. Außer für die kleinsten Dienste ist eine Art Lastausgleichsmechanismus erforderlich, um die Last eingehender Verbindungen auf die FE-Boxen zu verteilen. Viele Megadienste haben auch Unterdienste, die selbst lastausgeglichen sind. [Hervorhebung hinzugefügt]
Lastausgleich ist kein nachträglicher Einfall, sondern eine natürliche Ergänzung moderner Anwendungen und Dienste, um die erforderliche Skalierbarkeit (und Zuverlässigkeit) zu erreichen, die für die Zufriedenheit der Benutzer und den reibungslosen Geschäftsbetrieb erforderlich ist. Daher wird es immer wichtiger, dass der Lastenausgleich Teil der gesamten Anwendungsarchitektur ist. Und das sollte auch so sein, denn das Hinzufügen einer beliebigen Komponente zu einer Anwendungsarchitektur kann Probleme oder Integrationsschwierigkeiten mit sich bringen, die überwunden werden müssen. Probleme, die behoben werden müssen, bevor die App in Produktion geht, und nicht danach. Der Zeitaufwand zum Finden und Beheben von Problemen in der Produktion ist um ein Vielfaches größer als in Entwicklungs- oder Testumgebungen. Daher bedeutet die Einbeziehung des Lastenausgleichs in die Anwendungsarchitektur einen reibungsloseren (und schnelleren) Übergang in die Produktion und in die Hände der Benutzer.
Das bedeutet allerdings, dass Sie in der Lage sein müssen, den Load Balancer in die durch die DevOps-Toolchain automatisierten Prozesse zu integrieren, die die Integration und Bereitstellung in Entwicklungs- und Testumgebungen zunehmend vorantreiben. Dies bedeutet, dass ein umfassender Satz programmierbarer Tools wie APIs und Vorlagen bereitgestellt wird, die es ermöglichen, die Infrastruktur als Code zu behandeln und ihre Bereitstellung und Konfiguration zu automatisieren. Dies ist, was iControl (REST oder SOAP) für F5 macht.
Ein BIG-IP kann in den Bereitstellungs-, Test- und Releasephasen in DevOps integriert werden, indem man seine nativen APIs mit praktisch jeder beliebigen Sprache nutzt (hier sind Powershell , Python und Perl) oder über Frameworks wie Chef und Puppet und Tools wie Ansible und SaltStack . iApps , unsere Vorlagen, die eine Anwendungsdienstkonfiguration beschreiben, können wie Code behandelt werden: Speichern Sie ihn in Github, rufen Sie ihn ab und stellen Sie ihn unverändert bereit oder passen Sie ihn mit einem Skript an.
Grundsätzlich sollten BIG-IP-Anwendungsdienste wie Lastausgleich und viele seiner Anwendungsleistungs- und Sicherheitsdienste früher in den CI/CD-Prozess integriert werden, um sicherzustellen, dass diese kritischen Dienste wie erwartet nahtlos mit der Anwendung zusammenarbeiten.
Letztendlich werden wir immer mehr traditionelle „Netzwerkgeräte“ in eine DevOps-Welt integrieren, da der Druck, Anwendungen schneller, häufiger und mit weniger Unterbrechungen bereitzustellen, Unternehmens- und IT-Leiter weiterhin kopfüber in die Anwendungsökonomie treibt.
Um tiefer in die DevOps-Tools einzutauchen, die Sie mit BIG-IP verwenden können, sehen Sie sich diesen Beitrag auf DevCentral an: „ F5 Friday“: DevOps-Tools und F5 "