DevOps und Continuous Delivery sind heute de facto Standards in der Software-Entwicklung. Zumindest wenn man einigen Statistiken[1][2] glauben kann, die in den letzten Jahren veröffentlicht wurden.
Ich persönlich denke, dass die tatsächliche Verbreitung geringer ist als es diese Zahlen glauben lassen - alleine schon deshalb, weil es kein Rezept für DevOps gibt. Außerdem ist der Begriff sehr vage und überladen. Fragt man drei IT Professionals nach einer Definition bekommt man wahrscheinlich drei verschiedene Antworten. Manche setzen damit (zu Unrecht) Infrastructure-as-Code gleich, für andere ist es hauptsächlich ein organisatorischer oder kultureller Prozess.
Egal wie eng oder weit man es fasst, Automatisierung und Tool-Unterstützung spielen sowohl bei DevOps als auch bei Continuous Delivery eine wichtige Rolle. Aber der Markt für „DevOps-Tools“ ist genauso unübersichtlich wie die Begriffe selbst. Ich habe in letzter Zeit häufiger mit Kollegen über dieses Thema gesprochen und dabei kamen immer wieder Fragen auf wie: „Wozu brauche ich denn Chef [oder Puppet, Salt, Ansible...], wenn es doch schon PureApplication Systems gibt?“. Seit der Übernahme von UrbanCode im vergangenen Jahr hat IBM seine eigene DevOps Plattform weiter ausgebaut. Ist das nicht das gleiche wie der IBM Workload Deployer? Gibt es nicht das gleiche als Open-Source-Lösung?
Die (nicht sehr überraschende) Antwort ist: Nein, es ist nicht alles das gleiche.
Es macht Sinn sich alle angesprochenen Tools und Systeme anzuschauen weil sie sich gegenseitig ergänzen, nicht ersetzen.
Wie baut man einen Bauplan?
Die Stärke von PureApplication System ist es Anwendungen und die darunterliegende Infrastruktur, die durch Patterns abgebildet werden, in einer Cloud bereitzustellen. In vielen Fällen reichen dazu vorgefertigte oder selbst erstellte Application Patterns aus. Theoretisch lassen sich ganze Anwendungslandschaften damit aufsetzen und betreiben. Aber leider ist es nicht immer so einfach. Nicht alle Systeme fallen in ein typisches, weit verbreitetes Schema. Wenn neben Standard-Komponenten auch selbst entwickelte Tools, Frameworks, Scripte, Monitoring und sonstige Utilities benötigt werden (und seien wir ehrlich, das ist nicht selten), muss eine individuelle Lösung her. In PureApplication System heißt das System Patterns.
Um beliebige Systeme zu modellieren benötigt man im Wesentlichen zwei Teile: Ein Basis-Image (z.B. ein vorkonfiguriertes Linux System und Middleware) und Skripte, um die eigentliche Konfiguration zu automatisieren. In den meisten Fällen werden diese Skripte nicht nur aus ein paar Kommandos bestehen. Je größer und heterogener die verwalteten Umgebungen sind, desto weniger sollte man sich darauf einlassen sie von Grund auf selbst zu schreiben. Die Kosten für Wartung und Weiterentwicklung schießen dadurch nur unnötig in die Höhe.
Rezept des Tages: Virtual System Patterns
An dieser Stelle kommen Tools wie Chef oder Puppet ins Spiel. Ihre wesentliche Eigenschaft ist, dass sie die Konfiguration von Systemen in Form von Code abbilden können, meist ohne dass man sich mit Implementierungsdetails beschäftigen muss. Damit lässt sich praktisch jeder Zielzustand, von der Betriebssystemkonfiguration, über installierte Pakete bis zu laufenden Services beschreiben und reproduzieren. Weil diese Tools relativ leicht einzusetzen, aber gleichzeitig sehr mächtig sind, haben sie zu Recht mittlerweile viele Anhänger gefunden.
Die gute Nachricht ist, dass PureApplication System solche DevOps Tools unterstützt. Genauer gesagt setzt IBM auf Chef als Infrastructure-as-Code Anbieter. Es gibt einen frei verfügbaren IBM Script-Package Generator[3], mit dessen Hilfe Chef Skripte (auch Rezepte genannt) in Virtual System Patterns verwendet werden können. Auf diese Weise können auch sehr komplexe und individuelle Umgebungen automatisiert in der Cloud bereitgestellt werden.
Die schlechte Nachricht: Es gibt Dinge, die auch Chef und PureApplication System gemeinsam nicht optimal abbilden können.
Leben in die Cloud bringen
Was dieser Lösung noch zu einer vollen Continuous Delivery Pipeline bzw. DevOps-Toolunterstützung fehlt sind automatisierte Deployments auf die provisionierten Systeme. Damit meine ich nicht nur eine Datei, die auf einen Server kopiert wird, sondern komplette Releases, die Anwendungen, Datenbanken, Backendsysteme simultan betreffen.
Releases durchlaufen mehrere Stufen und Umgebungen, bevor sie in Produktion gehen. Jedes Deployment ist mit bestimmten Prozessen (manuelle und/oder automatisierte) verbunden und muss dementsprechend geplant und koordiniert werden. Für diesen Zweck gibt es Produkte wie UrbanCode Deploy und UrbanCode Release. Mit UrbanCode Deploy lassen sich Deployments über alle Stages hinweg automatisieren. Release setzt noch eine Ebene höher an und koordiniert, welche Änderungen an welchen Artefakten, auf welchen Umgebungen und zu welcher Zeit durchgeführt werden. Dadurch erhält man ein zentrales Tool zur Verwaltung eines Anwendungslebenszykluses. Die darunterliegende Infrastruktur kommt im Idealfall aus der Cloud – womit wir wieder bei PureApplication System wären. Aufbauend auf den zuvor erstellten System Patterns lässt sich damit die Bereitstellung von Umgebungen vergleichsweise einfach automatisieren.
Quelle: Sehenswerte Slideshare-Präsentation von Sanjeev Sharma [4]
Zusammengefasst ergibt sich aus den drei vorgestellten Produkten ein sehr mächtiges Set an Werkzeugen um eine Continuous Delivery Pipeline aufzubauen: UrbanCode Software für Release and Deployment Management, PureApplication System als Cloud Provider und Chef für die Infrastruktur-Konfiguration.
Die Implementierung dieser Lösung allein macht zwar aus Dev und Ops noch kein DevOps. Die Automatisierung großer Teile des Anwendungslebenszykluses nimmt aber viele Routineaufgaben ab und schafft Zeit für die wirklich schwierigen Aufgaben.
[1] http://velocityconf.com/velocity2013/public/schedule/detail/28446
[3] https://www-304.ibm.com/software/brandcatalog/ismlibrary/details?catalog.label=1TW10SO0M#tab-details
[4] http://www.slideshare.net/Urbancode/deliver-contuniously-to-cloud