Repositories und Standardisierung können helfen, Herausforderungen bei der Netzwerkautomatisierungsintegration zu bewältigen

Integration war schon immer ein Schimpfwort, denn es ruft bei denjenigen, die bei den Projekten zu seiner Umsetzung schwächeln, Zähneknirschen und Wehklagen hervor. Tatsächlich bezeichneten 59 % der IT-Entscheidungsträger die „Integration als die ‚Achillesferse‘ ihres Unternehmens.“ ( Der Connected Business Integration 2018 Report )

Oberflächlich betrachtet beginnt die Integration mit einer einfachen Prämisse: Wie teilen wir Daten zwischen Applications? Denn keine Application – nicht einmal ein Monolith – ist eine Insel. Mir ist noch keine Application begegnet, die nicht mindestens ein Datenelement mit einer anderen Application geteilt hat.

Wir (als Branche) haben mehrere Epochen der Integration durchlaufen. Von Hub-and-Spoke-Modellen über den Enterprise (Service) Bus bis hin zu Nachrichtenwarteschlangen ist die Integration immer ein integraler Bestandteil einer Application .

Wir nennen es nicht mehr Enterprise Application Integration (EAI) – hauptsächlich, weil ich glaube, dass das den jungen Leuten Angst macht und bei uns alten Hasen einen Schlaganfall verursacht – aber wir verwenden immer noch das Wort „Integration“. Und wir nutzen es zunehmend außerhalb der Welt der Application . CI steht schließlich für Continuous Integration . Wir erachten die Integration auch für die Bereitstellungs- (Produktions-)Seite der Welt als bedeutsam. Und wir erleben genauso viel Frustration wie unsere Kollegen aus der App-Entwicklung, wie diejenigen anmerken, die wegen des Mangels an integrierten Tools bei der Automatisierung des Netzwerks frustriert sind. 

Der Betrieb braucht Integration. Ohne sie können wir Prozesse nicht automatisieren (und das ist Orchestrierung), da sich Prozesse notwendigerweise über mehrere Systeme, Dienste und Geräte erstrecken – und jedes davon wahrscheinlich über seinen eigenen Betriebsbereich und sein eigenes Toolset verfügt. Ohne Integration können Sie keine Pipeline erstellen und ohne Pipeline werden die Betriebsabläufe durch die wachsenden Anforderungen an häufige Bereitstellungen auf Abruf überfordert.

Hier können Infrastruktur als Code und Repositories Abhilfe schaffen. Repositories sind mehr als nur ein Ort, an dem Sie praktisch jede Art von Artefakt speichern können, von der Konfigurationsdatei über das Python-Programm bis hin zu Skripten und Vorlagen. Sie können ein aktiver Teilnehmer an Ihrer (integrierten) Bereitstellungspipeline sein.

Repositorien sind mehr als nur Lagerkisten

Repositorien sind nicht nur Orte zur Aufbewahrung von Artefakten. Ich meine, ja, das ist ihr Hauptzweck, aber sie haben sich zu viel mehr als nur einem Lagerschrank entwickelt. Heute können Repositories wie GitLab und GitHub eine Schlüsselkomponente der automatisierten Pipeline sein. Durch die Verwendung von Triggern und Ereignissen fungieren Repositories nicht nur als Ort zum Speichern von Artefakten, sondern auch als Tools in einer größeren Toolchain. Durch „Commit“ wird ein Job gestartet, der nach Abschluss einen Webhook aufruft, der den nächsten Schritt in der Pipeline auslöst.

Was ist ein Webhook?

Ein Webhook, manchmal auch „Reverse API“ genannt, ermöglicht es einer Application – wie einem Repository –, Daten in Echtzeit über eine URL/API an eine andere Application zu senden. Wenn beispielsweise eine neue Konfiguration für Ihren Load Balancer übergeben wird, löst das Repository einen Webhook aus, der wiederum die Konfiguration oder URI für die Konfiguration an eine App (oder direkt an den Load Balancer) sendet, die wiederum die neue Konfiguration lädt.

Im Grunde verwenden wir Repositories auf die gleiche Weise, wie wir früher einen Enterprise Service Bus verwendet haben, um Daten auszutauschen und Aktionen in verschiedenen Applications und Diensten einzuleiten, um einen „Prozess“ abzuschließen. In der Geschäftswelt könnte dieser Prozess die Abarbeitung einer Kundenbestellung sein und das Kundeninformationssystem (CIS), ein Auftragserfüllungssystem, die Rechnungsstellung und Elemente der Lieferkette umfassen.

In der Betriebswelt umfasst dieser Prozess die Infrastruktur-, Netzwerk- und Sicherheitsdienste, die an der Bereitstellung einer Application oder Richtlinie beteiligt sind.

Noch spannender für diejenigen, die „Fähigkeiten“ als ihre größte Herausforderung genannt haben: Repositories können fast ausschließlich über die Befehlszeile gesteuert werden. Ja, und zwar unter Nutzung der gleichen Fähigkeiten, über die die meisten NetOps bereits verfügen. Ein bisschen Bash und etwas PERL*, eine API über Curl und voilà!

Damit wird jedoch nicht dem tieferen Bedarf an Integration auf Geräteebene Rechnung getragen, der sich in der Frustration über den Mangel an Anbieterlösungen äußert. Denn letztendlich müssen die im Repository gespeicherten und per Webhook ausgelösten Konfigurations- bzw. Konfigurationsänderungen noch in die Gerätesprache übersetzt werden.

Und hier kommen Standardisierung und Lösungen ins Spiel.

Standardisierung reduziert den betrieblichen Integrationsaufwand

Viele von uns bei F5 konzentrieren sich derzeit auf die Automatisierung. Eine der Lösungen, die wir entwickelt haben, ist unsere F5 Automation Toolchain . Es umfasst die F5 Application Services 3 Extension (AS3), F5 Declarative Onboarding (DO), F5 Telemetry Streaming und das F5 API Services Gateway. Zusammen mit einem Repository können sie Unternehmen ermöglichen, die Pipeline aufzubauen, die sie zum Bereitstellen der Application benötigen, die eine Application (und das Unternehmen) braucht, um Apps schnell, sicher und verfügbar zu halten.
 

Aber Lori, denken Sie, das hilft mir nicht bei all den anderen Geräten und Diensten, die ich automatisieren und integrieren muss.

WAHR. Dies ist eine der Möglichkeiten, bei denen die Standardisierung auf einer gemeinsamen Application hilfreich sein kann.  Da die Plattform (BIG-IP) für eine breite Palette von Application dieselbe ist, können Sie die Automatisierungs-Toolchain unter anderem zum Bereitstellen einer WAF, eines Load Balancers, einer Zugriffskontrolle und eines DDoS-Schutzes verwenden. Die Standardisierung auf möglichst wenige Plattformen schafft Mehrwert, indem sie den Integrationsaufwand für alle Vorgänge – Netzwerk, Infrastruktur und Sicherheit – reduziert.

Dies gilt innerhalb der Grenzen des Rechenzentrums und in einem Multi-Cloud-Szenario. Durch die Standardisierung auf einer einzigen Plattform für alle Application und Cloud-Umgebungen lässt sich die Wertschöpfungszeit bei der Bereitstellung von Apps überall verkürzen. 

Sie finden die (völlig kostenlose) F5 Automation Toolchain an mehreren Orten:

• Auf GitHub
• Auf Docker Hub
• F5 Ansible-Module

Denken Sie also daran, dass Repositories nicht nur ein Ort zum Speichern von Dingen sind. Sie sind ein wertvolles Werkzeug in Ihrem Automatisierungs-Werkzeugkasten, das Sie zur Automatisierung aller unterschiedlichen Teile Ihrer Pipeline nutzen können. Durch die Standardisierung eines Repository zusammen mit einer Application kann die betriebliche Belastung, die durch das vierbuchstabige Wort „Integration“ entsteht, erheblich reduziert werden. 

*interpretieren Sie „PERL“ als Python oder eine andere tatsächlich verwendbare Skriptsprache. PERL ist einfach das einzige, das sich auf curl reimt, und ich habe nichts Gutes gefunden, das sich auf wget reimt.