Ein stabiler, sicherer IT-Betrieb – darauf zielen Unternehmen, wenn sie den IT-Betrieb an Dienstleister und in externe Rechenzentren auslagern. Doch immer mehr Entwicklungsabteilungen entwickeln agil, wollen mehrere Releases pro Tag in den Betrieb geben. Wie lässt sich dies auf Basis von Continuous Delivery mit IT-Dienstleistern realisieren?
IT-Entwicklung (Development) und IT-Betrieb (Operations) haben sehr unterschiedliche Prioritäten. Der IT-Betrieb folgt der obersten Prämisse, dass Anwendungen sowohl stabil laufen als auch sicher und permanent verfügbar sein müssen. Ganz anderen Zielen folgt die IT-Entwicklung – insbesondere seit agile Entwicklungsmethoden Einzug gehalten haben. Hier gilt die schnelle Abfolge von Releases und neuen Funktionen als erstrebenswert, weil dies es ermöglicht, rasch auf veränderte Anforderungen des Marktes zu reagieren.
Das Ergebnis sind Spannungen und große Reibungsverluste. In vielen Unternehmen bilden IT-Betrieb und IT-Entwicklung »Silos«, die sich voneinander abschotten und sich nur selten konstruktiv abstimmen. Oftmals reden die beiden Abteilungen nur während des Release-Prozesses miteinander. Immer mehr Unternehmen fahren kommerziell wie technisch gut damit, das Management von Servern, Storage, Netzwerkinfrastruktur, Connectivity, Sicherheits- und Betriebssystemen in die Hände von Spezialisten zu legen. Aber dieser Trend, den IT-Betrieb an externe Dienstleister auszulagern, verbreitert die Kluft zwischen Development und Operations weiter.
Lösungsansatz DevOps. Doch Unternehmen brauchen künftig beides: den sicheren und zuverlässigen Betrieb und die kontinuierliche Bereitstellung neuer Funktionen und Releases (Continuous Delivery). Was also tun?
Die Abstimmung und Kommunikation zwischen Entwicklung und Betrieb verbessern – mit dieser Zielsetzung hat sich vor einigen Jahren die DevOps-Bewegung etabliert. Die große Stärke dieser Bewegung: Sie engt dieses Bemühen nicht auf Tools oder Schnittstellen ein, wie das bei Continuous Delivery der Fall ist. Stattdessen verfolgt die DevOps-Bewegung einen breiten Ansatz, verortet die Ursachen für die Spannungen zwischen Entwicklung und Betrieb beispielsweise in Zielkonflikten und definiert sie als kulturelles Problem. Es werden daher auch Prozesse, Methoden und die gesamte Organisation adressiert. Man kann DevOps als die logische Fortführung agiler Entwicklungsprozesse im Bereich der Betriebsführung sehen. So wird es möglich, kulturelle Gräben zu überwinden und zielführende Brücken zwischen interner IT-Entwicklung und externem IT-Betrieb zu bauen.
Fortschrittliche IT-Dienstleister bieten DevOps-Dienstleistungen, um das kontinuierliche Deployment agil entwickelter Software zu unterstützen.
Ohne Wissen über die Umgebungen, deren Performance und die Übergabe- und Testprozesse kann nicht entwickelt werden. Ohne Vorstellung über die Auswirkung neuer Funktionen auf Datenbanken, Server und andere IT-Ressourcen kann kein sicherer Betrieb gewährleistet werden. Diese Erkenntnis und die Erfahrungen mit Continuous Delivery lässt die ersten IT-Dienstleister reagieren: Sie etablieren DevOps-Teams. Deren Aufgabe ist es, die Zusammenarbeit mit den Entwicklungsteams des Kunden zu vertiefen und den Release-Prozess in Form einer Deployment-Pipeline gemeinsam zu automatisieren und zu optimieren.
Deployment auf Knopfdruck. Kommunikation und Abstimmung sind der Arbeitskern der DevOps-Teams. Aus dem Verständnis für die unterschiedlichen Anforderungen und Arbeitsweisen lassen sich Tool Chains und Prozesse etablieren, die den jeweiligen Anforderungen von Entwicklung und Betrieb entsprechen.
Die Vision: Mit DevOps-Dienstleistungen dieser fortschrittlichen IT-Dienstleister können Unternehmen Deployment-Pipelines aufbauen, die vom Unit-Test über Integration-Tests bis zum automatisierten Deployment in der Produktion reichen. Die Schnittstelle zwischen Entwicklung und Betrieb wird dabei durch die Deployment-Pipeline sowohl explizit definiert als auch überbrückt. Die dadurch mögliche weitgehende Automatisierung des Release-Prozesses macht diesen nicht nur in hoher Frequenz wiederholbar, sondern minimiert zugleich Fehlerrisiken im Betrieb. Dabei setzen DevOps-Teams auf bekannte Open-Source-Tools, die vielen Entwicklern bereits gut bekannt sind. Beispiele sind »Foreman« für die automatisierte Provisonierung oder »Puppet«, um Infrastruktur wie Source Code (»Infrastructure as Code«) behandeln zu können. Letzteres macht es möglich, Vorgänge und Konfigurationen über eine klassische Versionskontrolle zu erfassen und zu testen. Tools wie »Thoughtworks Go« oder auch »Jenkins« helfen bei der Steuerung der Deployment Pipeline.
Kunden profitieren von den Dev-Ops-Teams der IT-Dienstleister, weil diese neben Tools auch ihre praktischen Erfahrungen und Best Practices anderer Pioniere für Continuous Delivery in die Zusammenarbeit einbringen. Das minimiert Risiken und Kosten bei den notwendigen Anpassungen von Organisation, Prozessen und Tools. Unternehmen schaffen es schneller, die Zahl der Releases zu erhöhen und sich so Wettbewerbsvorteile zu erarbeiten. Erfolge werden durch Messungen auf Infrastruktur- und Applikationsebene überprüft und weiteres Verbesserungspotenzial aufgedeckt (Continuous Improvement) – auch dies ein Grundsatz der DevOps-Bewegung.
Ein Signal. Mit der Einrichtung von DevOps-Teams zeigen fortschrittliche IT-Dienstleister: Wir können nicht nur einen sicheren, kosteneffizienten Betrieb gewährleisten, sondern gemeinsam mit unseren Kunden in hoher Frequenz neue Releases in Betrieb nehmen – reibungsarm, weitgehend automatisiert und ohne negative Folgen auf den Betrieb. Das »Release auf Knopfdruck« ist die Ausdehnung agiler Methoden auf die IT-Operations.
Dr. Thomas Fischer,
Principal Architect bei der noris network AG