BLOG

Open Source im Rampenlicht: F5-Infrastruktur als Code und Multi-Cloud-Verwaltbarkeit

Lori MacVittie Miniaturbild
Lori MacVittie
Veröffentlicht am 16. November 2017

Ihnen ist vielleicht aufgefallen, dass Verwaltbarkeit ein wesentlicher Bestandteil des Multi-Cloud-Mantras ist. Der Grund hierfür ist, dass für die Skalierung, Sicherung und Bereitstellung von Apps für Benutzer bestimmte Dienste erforderlich sind – Lastenausgleich, Rechenleistung, Speicher, App-Sicherheit. Und obwohl die Cloud die Bereitstellung dieser Dienste möglicherweise (und tatsächlich) wesentlich vereinfacht, geschieht dies auf Kosten des Betriebs. Bedauerlicherweise verlagert es die Komplexität woanders hin.

Wenn Sie derjenige sind, der diese Dienste bereitstellt, ist alles in Ordnung. Aber wenn Sie derjenige sind, der die Dienste konfigurieren, optimieren und verwalten muss, ist das nicht so toll.

Weil Komplexität das Management erschwert. Keine zwei Clouds sind gleich (hinsichtlich APIs und Dienste) und das bedeutet oft, dass die Leute jetzt mit zwei völlig unterschiedlichen Betriebsmodellen arbeiten müssen.

Daher ist die Verwaltbarkeit ein wichtiger Faktor für den Erfolg einer Multi-Cloud.

DevOps_Zugriff_Einfluss_2017

Organisationen können dies unter anderem durch die Einführung von Konstrukten erreichen, die die Bereitstellung vereinfachen. Diese haben zunehmend die Form einer Art Vorlage: OpenStack HEAT, AWS Cloud Formation und Azure ARM fallen mir ein. Diese Vorlagen kodifizieren den Großteil einer BIG-IP-Bereitstellung im Hinblick auf die spezifische Konfiguration, die vorhanden sein muss, um den wahren Wert eines BIG-IP – seine Dienste – zu steigern.

Vorlagen sind eines der besten Beispiele für Infrastruktur als Code (IAC). Dies liegt daran, dass sie genau wie Code-Artefakte behandelt werden können. Sie können versioniert, verzweigt, zusammengeführt, abgerufen, geklont und schließlich bereitgestellt werden.

Dieses Modell passt gut zur DevOps-orientierten Sicht auf Cloud und Verwaltung durch APIs und Skriptsprachen. Wenn DevOps seinen Einfluss auf NetOps ausweiten kann und diese wiederum mithilfe eines IAC-Ansatzes schnell Dienste bereitstellen können, sind alle zufrieden. Das ist genau das Richtige, wenn man bedenkt, dass das Fehlen solcher Dienste von NetOps die Entscheidungen von DevOps, die IT zu umgehen, wenn es um die Cloud geht, erheblich beeinflusst.

Die Unterstützung der Multi-Cloud-Verwaltbarkeit ist genau das, was wir (das heutige Unternehmens-Wir) uns vorgestellt haben, als wir mit der Entwicklung von Vorlagen für OpenStack, AWS und Azure begannen. Um einen IAC-Ansatz zu ermöglichen, der mehr Agilität und Geschwindigkeit bietet, sind diese Vorlagen kostenlos über GitHub verfügbar.

Denn unsere Laboreinsätze sind nicht Ihre Einsätze und auch nicht die des anderen Typen (der in der Reihe hinter Ihnen sitzt und Ihnen über die Schulter liest). Bereitstellungen weisen zwar einige gemeinsame Merkmale auf, alle Apps haben jedoch spezifische Anforderungen, die nicht mit derselben standardisierten Servicekonfiguration erfüllt werden können. Für zustandslose, auf Microservices basierende Apps reicht das Round-Robin-Loadbalancing möglicherweise aus, für andere Application kann es jedoch äußerst ineffizient (und nicht zu vergessen teuer) sein – insbesondere in Cloud-Umgebungen. Sie benötigen die Freiheit, die App-Leistung anzupassen und zu optimieren und die Sicherheit der Daten und Benutzerinteraktionen zu gewährleisten.

Sie müssen in der Lage sein, diese Artefakte in Ihre eigenen Repositories zu ziehen, zu klonen und zu übertragen, damit Sie die Vorteile eines NetOps-Ansatzes nutzen können, der IAC umfasst, um einen möglichst großen Teil Ihrer Servicebasis in möglichst vielen Ihrer Cloud-Umgebungen bereitzustellen.

Führen Sie also das Pullen, Klonen, Commit und Bereitstellen gemäß Ihrem Zeitplan durch – ob das nun dreimal am Tag oder dreimal im Quartal ist. Es ist Open Source und jederzeit für den Zugriff offen.