Der Begriff „DevOps“ wird derzeit in vielen Unternehmen und IT-Projekten heftig diskutiert. Der Begriff kommt ursprünglich aus dem Bereich der Software-Entwicklung und beschreibt moderne Prozesse und Verfahren, um die traditionell oft gegenläufigen Interessen der IT-Bereiche Entwicklung („Development“) und Betrieb („Operations“) zusammenzuführen und so eine effizientere und effektivere Zusammenarbeit zu ermöglichen.
Viele erfolgreiche Projekte und Umsetzungen zeigen das Potential von DevOps:
Gerade bei den großen Software-Herstellern, aber auch in Unternehmen wie Lufthansa Systems oder Netflix ist DevOps mittlerweile der Standard für die Software-Entwicklung.
Das Versprechen von DevOps lässt sich so zusammenfassen: Schnellere Innovation ohne die Sicherheit, Stabilität und Verfügbarkeit des Gesamtsystems zu gefährden. Wer wünscht sich das nicht?
Es ist daher verständlich, dass das Interesse groß ist, DevOps-Prinzipien auch in anderen IT-Bereichen einzuführen. RZ- und Netzwerkbetreiber beispielsweise stehen unter großem Druck, ihre Basisinfrastrukturen effizient bereitzustellen und zu betreiben. Insbesondere im Rechenzentrum erfolgt derzeit unter der Bezeichnung Software-defined Datacenter (SDDC) eine Transformation mit vergleichbarer Zielsetzung. Anstatt mit vielen technologiegetriebenen funktionalen Teams hardware-orientierte Infrastruktur bereitzustellen (was gerne als Silobetrieb bezeichnet wird), verschiebt sich der Fokus hin zur automatisierten Bereitstellung ganzer Anwendungen inklusive aller benötigter Ressourcen und deren flexiblen Skalierung.
Das Ziel im RZ ist durchgehende Automatisierung über alle Ressourcen und Abteilungen hinweg, vom Netzwerk und Speicher über Server bis hin zu Betriebssystemen und Anwendungen. Ähnliche Anforderungen gibt es auch bei der Bereitstellung von Anwendungen in der Cloud. Die dort vorhandenen Orchestrierungstools werden daher von den Hypervisor-Herstellern auf den on-premises Betrieb übertragen.
SDDC und Private Cloud sind tatsächlich nicht sehr weit auseinander. Im Grunde fehlen nur noch Orchestrierungstools, um von einem SDDC zu einer Private Cloud zu kommen (zu Details siehe [1]).
Aber SDDC und Cloud Computing sind nicht allein eine Frage der richtigen Tools. Genauso wichtig – wahrscheinlich sogar noch wichtiger – sind die organisatorischen Veränderungen, die diese Techniken mit sich bringen:
Alle diese tief mit einander verwobenen Funktionen benötigen Teamwork, die interdisziplinäre Zusammenarbeit zwischen verschiedenen Teams.
DevOps basiert auf Teamwork
Damit sind wir bei DevOps. Denn auch bei DevOps geht es um engere Zusammenarbeit, um die Überwindung geläufiger Interessen. Schauen wir uns die Ideen hinter DevOps etwas genauer an.
Was ist traditionell das Kernproblem zwischen Entwicklung und Betrieb? Entwickler stellen neue Funktionen und Anwendungen zur Verfügung, auf die in der Regel die Kunden dringend warten. Ihre Aufgabe besteht darin, neue Funktionen so schnell wie möglich in den produktiven Betrieb zu bringen. Das Operating dagegen ist für Verfügbarkeit und Stabilität verantwortlich – neue Funktionen gefährden erfahrungsgemäß diese Bestrebungen. „Never change a running system“ ist einer der Lieblingssprüche von Administratoren. Und abgesehen davon bedeutet Change für den Betrieb auch schlicht Mehrarbeit: Änderungen der Konfiguration, Anpassung der Dokumentation, Know-how-Aufbau.
Es gibt also eine ganze Reihe geläufiger Interessen, die sich umso stärker auswirken, je weiter die beiden Abteilungen voneinander getrennt sind, je weniger Kenntnisse über aktuelle Projekte der Gegenseite vorhanden sind und je später solche Informationen ausgetauscht werden. DevOps versucht, diese Konflikte zu entschärfen.
DevOps ist Unternehmenskommunikation
DevOps ist aber kein Sammelsurium von Tools zur Automatisierung bestimmter Prozesse und auch keine Technologie, das Sie einkaufen können. Vielmehr beschreibt der Begriff eine Unternehmenskultur, in der Zusammenarbeit, Lernbereitschaft und Transparenz gelebt wird – und zwar angefangen vom ersten Konzept bis zur Umsetzung bzw. Einführung beim Kunden oder Anwender.
Das heißt: DevOps bedeutet vor allem eines: Kommunikation!
Und zwar eine veränderte Art von Kommunikation, die zu dem generellen Wandel, dem Kommunikation heute in Unternehmen unterworfen ist, passt (siehe auch [2]):
Sogenannte UCC-Tools wie Cisco WebEx Teams, Microsoft Teams, Slack, Unify Circuit und viele andere unterstützen diesen Wandel und werden dementsprechend in vielen DevOps-Projekten zur Basiskommunikation via Chat, zur internen Abstimmung und als Ablage und Dokumentenmanagementsystem eingesetzt.
Die andere Ebene, die durch IT-Werkzeugen unterstützt werden kann und sollte, ist Automation. Zwar gehört Automation nicht zwingend zur reinen Lehre von DevOps, trotzdem sind Automatisierungstool in den meisten DevOps-Projekten zentrale Elemente. In der Softwareentwicklung sind CI und CD ohne Automatisierungstool nicht umzusetzen.
Was bedeutet jetzt DevOps im Netzwerkbereich?
Offenkundig ist, dass DevOps nur in Umgebungen Sinn macht, die bimodal betrieben werden. Das heißt in IT-Umgebungen, wo der Betrieb einer sicheren und hochverfügbaren Netzwerkumgebung für den produktiven Betrieb von einer experimentellen Test- und Evaluierungsumgebung getrennt ist.
Wie beschrieben, unterstützt DevOps die Kommunikation zwischen beiden Bereichen und sorgt dafür, dass die Schnittstellen „breiter“ werden. „Breiter“ ist in diesem Zusammenhang sowohl zeitlich als auch in Verantwortungsbereichen zu verstehen: keine harten Übergaben mehr, stattdessen ein fließender Übergang, an dem beide Teams beteiligt sind. Eine häufig diskutierte Frage ist daher: „Macht der bimodale Betrieb überhaupt weiterhin Sinn?“ Hier spielt zweifellos die Größe der Umgebung eine wichtige Rolle.
Ein weiterer Treiber in diese Richtung ist sicherlich Virtualisierung. Die Möglichkeit, Netzwerkfunktionen als virtuelle Instanzen (Virtual Network Functions – VNFs) im Hypervisor, in virtuellen Maschinen oder auch Containern ausführen zu können, eröffnet natürlich ganz neue Wege für Tests und Evaluierung. Tools und Vorgehensweise aus dem Bereich „Bereitstellung von Servern“ können hier als Vorgabe dienen. Insbesondere Funktionen wie Templates oder Profiles sind für den Betrieb (Operations) einfache Mittel, um erarbeitete Vorgaben zuverlässig umzusetzen und – und das ist wesentlich! – sicherzustellen, dass dies auch so bleibt.
Die klassische Automatisierung im Netzwerkbetrieb basiert nämlich immer noch weitgehend auf Skripten. Die sind zweifellos hilfreich, um neue Geräte auszurollen oder Massenänderungen durchzuführen, können aber nicht verhindern, dass nachträglich manuelle Änderungen gemacht werden. Und von einer automatischen Dokumentation solcher Änderungen sind wir da weit entfernt.
Tools wie Ansible und Puppet schließen mittlerweile diese Lücke und ermöglichen automatisch überprüfbare Profile nicht nur für virtuelle Appliances, sondern auch für Hardware-Geräte.
Darüber hinaus werden zunehmend Netzwerkdienste und Konfigurationen von Netzwerkgeräten über SDN (Software Defined Networking) gesteuert. Auch hierüber bieten sich weitere Automatisierungsmöglichkeiten, um selbst dynamische, zum Beispiel eventgeführte Änderungen nachvollziehbar und compliance-konform umzusetzen.
Auf der Automatisierungsseite gibt es also genügend Hilfsmittel für DevOps im Netzwerkbereich. Die größere Aufgabe wird aber sicherlich sein, die oben beschriebenen Prinzipien zur Zusammenarbeit und Transparenz in die Köpfe der Mitarbeiter zu bringen. Wie gesagt, DevOps ist vor allem ein kulturelles Thema. Packen wir’s an.
Referenzen
[1] Seminar„Software-Defined Data Center – Virtualisierung in der Analyse“ der ComConsult Akademie: https://www.comconsult-akademie.de/sddc-virtualisierung/
[2] Cornelius Höchel-Winter, „Digitalisierung und New Work“: https://www.comconsult.com/digitalisierung-new-work/
Der Netzwerk Insider gehört mit seinen Produkt- und Markt-Bewertungen rund um IT-Infrastrukturen zu den führenden deutschen Technologie-Magazinen. Der Bezug des Netzwerk Insiders ist kostenlos.
ComConsult GmbH
Pascalstraße 27
DE-52076 Aachen
Telefon: 02408/951-0
Fax: 02408/951-200
E-Mail: info@comconsult.com
