Over and Out für Command und Control Wie nur? Wie in einem Multicloud-Ökosystem die Kontrolle behalten?

Autor / Redakteur: Mike Bushong* / Ulrike Ostler

Die Migration in die Cloud kann befreiend wirken. Sie erlaubt IT-Teams die Tools und Praktiken zu nutzen, die von den Cloud-Titanen entwickelt wurden und ebnen den Weg in eine agilere IT-Umgebung. Allerdings geht diese Geschwindigkeit zu Lasten der Kontrolle. Wie können IT-Teams die Agilität der Cloud mit der Art von Kontrolle kombinieren, die moderne Unternehmen benötigen?

Anbieter zum Thema

Ein 'Command und Control' ist im Multicloud-Betrieb unmöglich. Dennoch dürfen sich Unternehmen dem Spiel der Gewalten nicht aussetzen. Wie sich dieser Konflikt lösen lässt, erläutert Mike Bushong von Juniper Networks.
Ein 'Command und Control' ist im Multicloud-Betrieb unmöglich. Dennoch dürfen sich Unternehmen dem Spiel der Gewalten nicht aussetzen. Wie sich dieser Konflikt lösen lässt, erläutert Mike Bushong von Juniper Networks.
(Bild: ©Vladyslav Danilin - stock.adobe.com)

Die Unternehmens-IT hat traditionell auf Basis eines strikten Command-and-Control-Modells gearbeitet. Das Verhalten wird durch eine Konfiguration bestimmt, die präzise auf einer verteilten Infrastruktur aufsetzt. Wird etwas überarbeitet, muss die IT diese Konfigurationsänderungen zunächst vorschlagen.

Es gibt allerdings eine Reihe von Nachteilen hinsichtlich dieses Modells. Zum einen wird die Infrastruktur ziemlich anfällig, wenn sie von der Art der Betriebspräzision abhängt, die erforderlich ist, um das spezifische Verhalten der verschiedenen Infrastrukturen zu beschreiben. Dies ist ein wichtiger Grund dafür, dass viele Unternehmen Frameworks wie ITIL einsetzen.

Wenn Änderungen schwierig sind, ist das Beste, was Sie tun können, die Überprüfung bis ins kleinste Detail. Damit ist eine entsprechende Agilität und Flexibilität nur sehr schwer zu erreichen. Das Ergebnis sind übermäßige Änderungskontrollen während kritischer Phasen.

Wird das Verhalten durch eine niedrige, gerätespezifische Konfiguration bestimmt, sind die Mitarbeiter auch Spezialisten, die die Hersteller-Konfiguration beherrschen. Die Herausforderung dabei: Diese Experten verfügen nur über einen sehr engen Fokus, was es Unternehmen erschwert, sich weiter zu entwickeln.

Die Qualifikationslücke, auf die viele Unternehmen treffen, wenn sie in die Cloud wechseln? Dies verschlimmert sich durch die historische Abhängigkeit von den bereits genannten Spezialisten, deren Fähigkeiten sich oft nicht auf andere Infrastrukturen übertragen lassen.

Übersetzung von Befehls- und Kontrollfunktionen in die Cloud

Command- and Control-Unternehmen wissen oftmals nicht, wie der Weg in die Cloud für sie aussieht. Einfach die Command- and Control-Praktiken auf die Public Cloud zu übertragen, stellt den Sinn der Cloud in Frage, auch wenn sie eine einfache Entwicklung darstellt. Zur Einführung von Cloud-fähigeren Betriebsmodellen müssen Mitarbeiter ausgebildet werden – das führt zu einer nicht-technischen Abhängigkeit, die sich schwer bewältigen lässt.

Die Lösung liegt darin, die bestehenden Betriebsabläufe über die Geräte hinaus zu verbessern. Technologietrends wie SDN sind wichtig, weil sie eine Abstraktionsebene einführen. Diese ermöglicht es den Betreibern, sich eher mit dem Intent als mit der Gerätekonfiguration zu befassen. Ob Overlay-Management im Rechenzentrum oder Cloud-basiertes SD-WAN: es gibt Lösungen, die Unternehmen den Weg von einer CLI-getriebenen zu Controller-basierten Steuerung ebnen sollen.

Dies trägt dazu bei, dass Cloud-Modelle sich schnell beweisen können. Im Idealfall dient es auch dazu, die Mitarbeiter auf moderne Betriebsmodelle umzuschulen, ein entscheidender Erfolgsfaktor für jedes Unternehmen, das in der Cloud erfolgreich sein will.

Intent-basiertes Richtlinien-Management

Eine abstrahierte Kontrolle ist von Bedeutung, denn sie führt auf natürliche Weise zu einer zielgerichteten Steuerung (intent-based). Intent-based Management bedeutet, dass die Betreiber das gewünschte Verhalten geräteunabhängig spezifizieren, so dass die Orchestrierungsplattform diese Absicht in zugrunde liegende Geräte-Stammfunktionen übersetzen kann.

Ein IT-Entwickler sollte nicht angeben müssen, wie eine Anwendung sich mit einem Benutzer verbinden soll. Egal, auf welchem VLAN es geschieht oder über eine Fabric, die dieses oder jenes Protokoll verwendet, ist weitgehend uninteressant. Stattdessen sollten IT-Teams nur das gewünschte Ergebnis angeben müssen: Anwendung A sollte in der Lage sein, mit Anwendung B zu sprechen, indem er die gewünschten Sicherheitsrichtlinien verwendet und Personen einer bestimmten Rolle Zugang gewährt.

Indem sie das Management zum Intent erheben, tun Teams zwei Dinge: Zunächst beherrschen sie die Dinge, die für ihr Unternehmen wichtig sind. Keine Abteilung interessiert, wie die Edge Policy konfiguriert wird. Sie interessiert vor allem, welche Anwendungen und Services ihnen zur Verfügung stehen. Indem sie den Intent der zugrunde liegenden Infrastruktur abstrahieren, schaffen die Betreiber eine entsprechende Portierbarkeit.

Multicloud und Portierbarkeit

Dies ist extrem wichtig, um die Kontrolle in einer Umgebung zu behalten, in der die Infrastruktur sich über Private und Public Ressourcen erstreckt. Ist die Abstraktion gut realisiert, sollte sich der Intent über jede zugrunde liegende Infrastruktur implementieren lassen.

Egal, ob die Anwendung in einem privaten Rechenzentrum oder AWS oder Azure betrieben wird: Der Vorsatz sollte der gleiche sein. Auf dieser Basis lässt sich jede zugrunde liegende Implementierung warten, wenn sie mit einer erweiterbaren Orchestrierungsplattform mit einer entsprechenden Reichweite und unterschiedlichen Ressourcen verknüpft ist.

Wenn ein Applikations-Workload beispielsweise in AWS abgespeichert ist, legt eine entsprechende Richtlinie fest, welche Funktionen das „AWS Virtual Private Cloud“ (VPC) Gateway betreffen. Wird der gleiche Workload zu Azure migriert, lässt sich der Vorsatz automatisch auf die entsprechende Azure Konfiguration transferieren – und zwar ohne Eingreifen des Betreibers.

Beim Launch eines Workload in einem privaten Rechenzentrum auf einer virtuellen Maschine (VM), sollte dieselbe Policy genutzt werden. Transferieren Unternehmen die Anwendungen in einen Container, sollte die Richtlinie die Gleiche sein.

Organisationen behalten somit die Kontrolle, indem die Richtlinien portabel sind. Auch wenn die darunter liegende Implementierung unterschiedlich sein kann: Das Verhalten sollte einheitlich sein. Die Voraussetzung dafür sind Multicloud-Management-Plattformen, die Multi-Domain- und Multivendor-Unterstützung bieten. Darüber hinaus müssen sich verschiedenen Application Lifecycle Management Plattformen zumindest teilweise integrieren lassen. Der Schlüssel, um die Kontrolle aufrecht zu erhalten, ist allerdings das Arbeiten auf dieser abstrahierten Ebene.

Vertrauen, aber verifizieren

Die Kontrolle zu haben, aber nicht verifizieren zu können, ist nicht besser als ein kompletter Kontrollverlust. Damit ein Betriebsmodell nachhaltig ist, muss es letztlich kontrollierbar sein. Dies gilt sowohl aus Management- wie auch aus Compliance-Sicht. Das bedeutet, dass Unternehmen, die die Kontrolle in einer Post-Cloud-Welt aufrechterhalten wollen, geeignete Überwachungsinstrumente einsetzen müssen, die ihnen Einblick in das Geschehen geben. Ähnlich wie bei der Diskussion hinsichtlich der Portierbarkeit von Richtlinien müssen diese Tools jedoch auf jede Betriebsumgebung erweiterbar sein – Public oder Private, Bare-Metal-Server oder virtualisiert, Cloud A oder Cloud B.

In den meisten Unternehmen arbeitet die IT in diskreten Silos, das heißt, das Anwendungs- und das Netzwerkteam werden getrennt voneinander betrieben. Das für das Rechenzentrum verantwortliche Team arbeitet unabhängig vom Campus- und vom Niederlassungsteam. Wenn Transparenz die Voraussetzung für Kontrolle ist und sich diese über die gesamte Multicloud-Infrastruktur erstrecken soll, müssen diese Teams zusammenarbeiten. Nur dann lässt sich das komplette Multicloud-Ökosystem beobachten.

Tools wie Performance-Monitoring und Network Paket Broker müssen nicht in domänenspezifischen Kontexten bewertet werden, sondern über die gesamte End-to-End-Umgebung hinweg. Dies kann bedeuten, dass ein Tool ausgetauscht wird, wenn ein anderes über mehrere Domänen hinweg besser geeignet ist.

Im Idealfall lassen sich diese Tools in eine breitere Orchestrierungsplattform integrieren, so dass beobachtbare Ereignisse zusätzliche Aktionen auslösen können (wenn dies, dann das / if this, then that).

Mit der Unternehmenskultur beginnen

Selbstverständlich gibt es gewisse Abhängigkeiten der zugrunde liegenden Technologie. Der Schlüssel, um in der Cloud ebenfalls die Kontrolle zu behalten, ist aber der gleiche Faktor wie bei einem Großteil der IT: die Menschen. Unternehmen sollten die Technologien bewerten, aber sie sollten beim Menschen beginnen, denn sonst ist der künftige Weg nur teilweise geebnet.

Das Coaching von Teams, um ihren Aufgabenbereich über die Geräte hinaus zu erweitern, ist die Voraussetzung für jede Cloud-Transformation. Entscheidend ist, dass Unternehmen sich von CLI-zentrierten Betriebsmodellen lösen. Darüber hinaus ist es wichtig, dass sie sich für eine vielfältigere Infrastruktur öffnen.

Der Cloud sind Legacy-Produkte egal, die auf traditionelle Weise verwaltet werden. Mit flexiblen und willigen und geschulten Teams kann die Technologie, auf der das Multicloud-Management basiert, effektiv eingesetzt werden. Damit erhält das Unternehmen das Beste aus beiden Welten: Agilität und Kontrolle.

* Mike Bushong ist Vice President, Enterprise and Cloud Marketing, Juniper Networks.

(ID:46063780)