BLOG

Dienstleister am Rande: Gemeinsame Automatisierungsframeworks und das Ende von Geschwindigkeits- und Sicherheitskompromissen

Bart Salaets Miniaturbild
Bart Salaets
Veröffentlicht am 10. Februar 2020

In der noch nicht allzu fernen Vergangenheit der Branche der Dienstanbieter gab es eine klare Trennlinie.

Auf der einen Seite trieben Netzwerk- und Sicherheitsteams die Entwicklung hin zu einer NFV-Architektur voran, mit einem starken Fokus auf der Virtualisierung von Netzwerk- und Sicherheitsfunktionen. Die Vorstöße in die Welt der Automatisierung waren bestenfalls zaghaft.

Auf der anderen Seite haben Entwickler Cloud-Plattformen, DevOps- Methoden und Automatisierung über CI/CD-Pipelines begeistert angenommen. Die schnelle Bereitstellung und Auslieferung von Anwendungen war und ist das A und O.

Beides kommt am Rand zusammen, und Anwendungen können harmonisch Seite an Seite mit Netzwerkfunktionen existieren.

Dank seiner verteilten Natur und vorangetrieben durch die schrittweise weltweite Einführung von 5G ermöglicht Edge Computing den Dienstanbietern endlich, neue Lösungen und Dienste anzubieten, die gleichzeitig die Einnahmequellen steigern und die Netzwerktransportkosten senken.

Anstatt Daten zur Analyse an die Cloud oder ein zentrales Data Warehouse zu übertragen, kann die Verarbeitung am „Rand“ eines Netzwerks erfolgen. Dies reduziert die Netzwerklatenz, erhöht die Bandbreite und sorgt für deutlich schnellere Reaktionszeiten.

Nehmen Sie selbstfahrende Autos.

Das Hosten von Anwendungen mit allen zugehörigen Daten an einem zentralen Standort wie einer öffentlichen Cloud kann zu End-to-End-Latenzen im zweistelligen Millisekundenbereich führen. Das ist viel zu langsam. Sie erhalten das gleiche Ergebnis, wenn die Anwendung zentral bleibt und die Netzwerkfunktion an den Rand verschoben wird. Wenn Sie die Anwendungs- und Netzwerkfunktion jedoch an den Rand verschieben, können Sie die Latenz auf Millisekunden reduzieren. Jetzt sind wir im Geschäft.

Virtualisierte Content Delivery Networks (CDN) sind ein weiteres überzeugendes Beispiel hierfür.

Bisher wurde ein CDN eines Drittanbieters in der Regel an einem Peering-Punkt oder in einem zentralen Rechenzentrum gehostet. Dies ändert sich nun, da einige clevere Dienstanbieter ihre eigenen CDNs auf der Basis von Edge Computing aufbauen, um lokale Videoinhalte und IPTV-Dienste abzudecken und dabei gleichzeitig Transit- und Backhaul-Kosten zu sparen.

Um derartige Anwendungsfälle umzusetzen, stehen unterschiedliche Geschäftsmodelle zur Verfügung.

Das einfachste Szenario ist ein Dienstanbieter, der den physischen Zugriff auf einen Edge-Compute-Standort gestattet. Dritte bringen ihre eigene Hardware mit und verwalten alles. Der Dienstanbieter ist für Platz, Strom und Konnektivität verantwortlich (auch als Colocation-Modell bekannt).

Ein weitaus interessanterer Ansatz besteht für den Dienstanbieter darin, über eine gemeinsam genutzte Edge-Compute-Plattform Dritten Infrastructure-as-a-Service- (IaaS) oder Platform-as-a-Service- (PaaS) Optionen anzubieten. Diese können Dienstleister selbst oder mit spezialisierten Partnern erstellen.

Die Macht der Automatisierung

Automatisierung ist die geheime Zutat, damit alles funktioniert.

Im Kontext des Cloud Computing ist die Automatisierung für Entwickler von entscheidender Bedeutung, um neue Codeversionen schnell und flexibel zu veröffentlichen.

In der Netzwerkwelt von NFV ist Automatisierung der Schlüssel zur Senkung der Betriebskosten eines Dienstanbieters. Bisher waren die Bereitstellung von Netzwerken und Diensten manuelle und zeitaufwändige Aufgaben. Auch wenn die Ziele heute unterschiedlich sein mögen, sind die Werkzeuge und Techniken für Netzwerk- und Entwicklerteams dieselben – oder können gemeinsam genutzt werden. Anwendungen und Netzwerkfunktionen existieren nebeneinander in einer Edge-Compute-Umgebung.

Wie können Entwickler also die Bereitstellung von Anwendungen und zugehörigen Anwendungsdiensten in der Cloud automatisieren?

In diesem Artikel konzentrieren wir uns auf die Automatisierung von Anwendungsdiensten. Es ist erwähnenswert, dass die unten beschriebenen Schritte problemlos in beliebte Konfigurations- und Bereitstellungsverwaltungstools wie Ansible oder Terraform integriert werden können, die dann durch CI/CD-Pipeline-Tools wie Jenkins ergänzt werden.

Der erste Schritt ist das Bootstrapping oder die Einführung der virtuellen Maschine, um Anwendungsdienste in die Cloud Ihrer Wahl bereitzustellen.

Als Nächstes folgt das Onboarding, das die Einführung einer grundlegenden Konfiguration mit Netzwerk- und Authentifizierungsparametern (z. B. IP-Adressen, DNS-Server usw.) beinhaltet. Schließlich erfolgt die eigentliche Bereitstellung von Anwendungsdiensten – wie ADC oder Sicherheitsrichtlinien – mithilfe deklarativer Anwendungsprogrammierschnittstellen (API).

Der letzte Punkt ist kritisch.

Imperative APIs, über die die meisten Anbieter verfügen, bedeuten, dass Sie dem System an jeder Stelle mitteilen, was es tun soll. Ein gutes Beispiel sind Firewalls. Sie müssen Adresslisten erstellen und diese an die Firewall-Regeln anpassen. Diese werden dann in einer Richtlinie zusammengefasst, die anschließend einer Schnittstelle zugewiesen wird. Es gibt verschiedene Schritte und Anforderungen für Rest-API-Aufrufe, die der Reihe nach ausgeführt werden müssen, sonst schlägt alles fehl. Das Integrieren all dieser Elemente in ein Automatisierungstool ist teuer und zeitaufwändig.

Deklarative APIs sind eine ganz andere Sache. Sie sagen dem System, was Sie wollen, und es findet den Weg nach vorne heraus. Mit einer Deklaration (im JSON- oder YAML-Format) können Sie beispielsweise alle ADC- und Sicherheitsdienstparameter definieren und diese mit einem einzigen Rest-API-Aufruf an das System weitergeben. In diesem Fall ist das Ergebnis entweder erfolgreich (der Dienst wurde bereitgestellt) oder es ist ein Fehler aufgetreten, das Gesamtsystem bleibt jedoch davon unberührt. Es ist keine Intelligenz im Automatisierungssystem erforderlich. Die Intelligenz verbleibt in den Systemen, die Sie konfigurieren, was die Automatisierungskosten drastisch senkt.

Zum Bereitstellen einer virtuellen Netzwerkfunktion in einer NFV-Umgebung können genau dieselben Schritte ausgeführt werden. Eine deklarative API vereinfacht die Integration mit End-to-End-NFV-Orchestrierungstools deutlich. Der Orchestrator muss die einzelnen Schritte zum Konfigurieren eines Dienstes oder einer Netzwerkfunktion nicht kennen, sondern überträgt lediglich eine einzelne JSON-Deklaration mit den Parametern, die das System zum Einrichten des Dienstes benötigt. Auch hier gilt, dass die Informationen zur Konfiguration des Dienstes beim System verbleiben, das Sie konfigurieren.

Durch eine engere Abstimmung zwischen Netzwerk- und Entwicklerdisziplinen können wir jetzt eine verteilte Telko-Cloud mit einem gemeinsamen Automatisierungsframework für Anwendungen und Netzwerkfunktionen erstellen. Es ist auf jeder Ebene des Stacks agil und sicher – vom zentralen Rechenzentrum bis zum äußersten Rand und sogar bis in die öffentliche Cloud.

Wir gehen davon aus, dass sich branchenweit gemeinsame Automatisierungsframeworks, die die Bereitstellung von Anwendungen und deren Diensten sowie Netzwerkfunktionen ermöglichen, in den kommenden Jahren zur Norm entwickeln werden – insbesondere angesichts des weltweiten 5G-Rollouts. Der Druck auf die Dienstanbieter steigt, Silos zu vereinheitlichen, agil zu werden und stärker am Rande der Realität zu leben.

Sie können auch hier klicken , um sich eine Keynote von Bart Salaets zum Thema Edge Computing vom jüngsten SDN NFV World Congress anzusehen.