Fünf Grundsätze, mit denen sich der Erfolg von DevOps messen lässt
An einem Strang
Während es in der DevOps-Diskussion vielfach vordergründig um Tools und Werkzeuge geht, versteckt sich hinter dem Begriff eine Philosophie, die ein Umdenken im ganzen Unternehmen erfordert. Eine neue Definition stellt die zwischenmenschlichen Aspekte in den Mittelpunkt, die für den Erfolg – oder das Scheitern – des DevOps-Ansatzes entscheidend sind.
DevOps, 2009 als Begriff vom belgischen IT-Berater Patrick Debois geprägt, ist aus modernen IT-Abteilungen nicht mehr wegzudenken. Die althergebrachte Zweiteilung in Sysadmins und Softwareentwickler muss einem neuen Paradigma weichen, in dem Development (Dev) und Operations (Ops) in agilen Teams aufgehen. Die umfassende Automatisierung der Bereitstellung von Software in der Produktion mittels Continuous Integration (CI) und Continuous Deployment (CD) ist dabei das erklärte Ziel des Ansatzes. Die neue Gattung der „DevOps Engineers“ verdient so viel wie Softwareentwickler und fast doppelt so viel wie Systemadministratoren (siehe ix.de/ix1812104).
Diese Transformation ist jedoch weiterhin eine der größten Herausforderungen für IT-Abteilungen in allen Branchen und allen Größen. Mit der Entscheidung für ein bestimmtes DevOps-Tool ist es nämlich nicht getan [1]. Mehr als auf die konkreten Werkzeuge kommt es auf die Integration aller Tools und Prozesse in eine konsistente Automationsplattform an, in der alle Aspekte einer Anwendung – von der Idee über das Live-Gehen bis hin zur Abschaltung – durchgehend automatisiert werden.
Unternehmensumbau – von horizontal zu vertikal
Klassische IT-Bereiche sind nach Funktion strukturiert: Ein Operations-Team kümmert sich um den Betrieb der Systeme, ein Team von Datenbankexperten stellt Datenbanken bereit, Backup-Fachleute führen Sicherungen und Wiederherstellungen durch, Anwendungsbetreuer kümmern sich um die Nöte der Mitarbeiter und passen Konfigurationen an. Qualitätssicherung ist die Verantwortung des QA-Teams und Sicherheit liegt in den Händen eines Security-Teams. Jedes Team baut seine eigene Automation für die eigenen Schichten. Eine übergreifende Automation oder eine Integration der verschiedenen Schichten ist zumeist nicht vorhanden.
In der DevOps-Philosophie ist genau das Gegenteil angesagt. „You build it, you run it“ lautet die von Amazons Chief Technology Officer und Vizepräsident Werner Vogels geprägte Aussage, die dieses Vorgehensmodell auf den Punkt bringt. Sie bedeutet, dass ein Entwicklerteam nicht nur Software erstellt, sondern darüber hinaus für die stabile Lauffähigkeit im Produktivbetrieb verantwortlich ist. In manchen Organisationen gilt die abgewandelte Form „You own it, you run it“. Das trägt der Tatsache Rechnung, dass einmal gebaute Software in der Praxis nicht unbedingt beim gleichen Team bleibt. Verantwortungsbereiche ändern sich, Teams werden neu organisiert und Software extern eingekauft.
Eigenverantwortung lässt sich vorrangig durch die eigene und unabhängige Handlungsfähigkeit definieren. Das bedeutet nicht zwangsweise, dass ein Team alle Facetten bis in die tiefsten Untiefen seiner Linux-Server beherrschen muss. Es muss jedoch seine alltägliche Arbeit ohne Abstimmungsaufwand erledigen können. Dabei sollten möglichst standardisierte Tools und Prozesse zur Verfügung stehen, die von anderen Teams als interne Produkte bereitgestellt werden.
Es ist mittlerweile eine Standardempfehlung für größere Unternehmen, professionelles Produktmanagement auch für interne Plattformen zu betreiben. Dabei geht es im Kern darum, die eigenen Entwickler als Kunden zu verstehen – ganz im Sinne der „Customer Centricity“-Bewegung, die die Interessen des Kunden in den Mittelpunkt aller Unternehmensentscheidungen stellt.
Solche Plattformteams betrachten den Gesamtprozess, der im Lebenszyklus einer Software entsteht: von der Idee über die erste Liveschaltung und die ständige Weiterentwicklung bis hin zum schlussendlichen Abschalten. Ihr Produkt ist eine Entwicklungs- und Betriebsplattform, auf der Entwicklungsteams möglichst einfach und schnell ihre Software erstellen und in hoher Qualität in die Produktion bringen können. Alle funktionalen und nicht funktionalen Anforderungen des Unternehmens werden in eine solche Plattform eingebaut und automatisiert.
Mit gutem Beispiel voran: die großen Drei
Wie DevOps in der Praxis geht, machen die großen Anbieter von Public Clouds vor: Alle von Google, Amazon und Microsoft angebotenen Dienste lassen sich nicht nur per GUI händisch verwalten, sondern sind über APIs und Orchestrierungswerkzeuge nutzbar. Die APIs ermöglichen es, die Cloud-Ressourcen mit externen Tools zu verwalten. Mit den Orchestrierungswerkzeugen, wie CloudFormation bei Amazons AWS, lassen sich umfangreiche IT-Landschaften mithilfe einfacher YAML-Dateien beschreiben und immer wieder aufs Neue zum Leben erwecken. Der Nutzer der Cloud-Plattform verwaltet seine Ressourcen in der Cloud selber und eigenverantwortlich – echter Self-Service.