Startseite > Blog-Artikel > DevOps: Eine (neue) Brücke zwischen Software-Entwicklung und IT-Betrieb

DevOps: Eine (neue) Brücke zwischen Software-Entwicklung und IT-Betrieb

Unternehmen, die Anwendungen für den Eigenbedarf im eigenen Haus entwickeln, folgen dabei meist einer passenden (agilen) Software-Entwicklungsmethode. Unternehmen, die IT-Systeme in größerem Umfang für den Eigenbedarf im eigenen Haus betreiben, versuchen dies durch ein IT Service Management Konzept (wie ITIL) zu optimieren.

Unternehmen, die beides machen, stehen vor dem Problem, dass diese beiden Bereiche teils widersprüchliche Ziele verfolgen: Veränderung  bei der Software-Entwicklung versus Stabilität bei Operations. Ein deutliches Zeichen für die Existenz des Problems sind Reibereien zwischen Projekt-Teams und dem IT-Betrieb.

Devops-Schriftzug als BrückeUnter der Abkürzung DevOps (aus Development + Operations, anfangs auch Dev2Ops abgekürzt) formiert sich seit etwa zwei Jahren eine Bewegung, die dieses Thema adressiert und Lösungen dafür sucht und anbietet. Ganz grob kann man DevOps als Brückenbau zwischen Entwicklern und Administratoren bezeichnen.

Warum muss eine (neue) Brücke gebaut werden?

Der Release-Prozess ist an vielen Stellen beschrieben (in Projektmanagement-, Software-Entwicklungs- und Betriebs-Konzepten) – aber leider nicht einheitlich. Als Folge daraus entsteht vielerorts eine fast natürliche Feindschaft zwischen Entwicklern und Administratoren. Diese beiden Gruppen müssen nämlich genau an dieser Stelle zusammen arbeiten, bringen jedoch unterschiedliche Anforderungen und Ziele mit.

Das Ansinnen der Entwicklung ist es, dem Fachbereich möglichst schnell die geforderten neue Funktionen zur Verfügung zu stellen, bei einem agilen Vorgehen soll dies sogar in einer hohen Frequenz passieren („Release often!“). Der IT-Betrieb wird jedoch meist an Verfügbarkeit und Stabilität gemessen und ist dementsprechend sehr skeptisch gegenüber Änderungen („Never change a running system“). Auch bei den anderen ITIL-Prozessen, die eine maßgebliche Schnittstelle zu Entwicklungs-Teams haben (Change, Incident, Problem und Configuration Management), bemerkt man in der Praxis meist überall diese Reibung, bedingt durch unterschiedliche Teilziele der Beteiligten.

Was tun mit diesen, sich augenscheinlich widersprechenden Forderungen? Meist wird das Ergebnis davon bestimmt, welcher Bereich im Unternehmen den einflussreicheren Leiter oder Fürsprecher hat. Und das geht dann zu Lasten der „anderen Seite“ – es gibt also entweder unstabile und pflege-intensive Anwendungen in der Produktion oder Unflexibilität, Trägheit und lange Reaktionszeiten bei der Erfüllung geschäftlicher Anforderungen.

Dass das übergeordnete Ziel – das Geschäftsziel – ein Kombination aus den beiden Teilzielen darstellt, wird im Eifer des Gefechtes vergessen.

DevOps möchte an dieser Stelle den Blick der Beteiligten für das gemeinsame Ziel öffnen und die Zusammenarbeit verbessern und erleichtern.

Wie soll die Brücke aussehen?

Die DevOps-Bewegung befindet sich noch in einer Phase, in der um die konkreten Bestandteile und deren Ausprägung gerungen wird. Bisher ist folgendes festgehalten:

  • Hohe Release-Frequenz: Nach DevOps arbeitende Unternehmen sollen in der Lage sein, die zur agilen Entwicklung gehörenden, kurzen Release-Abstände zu verwirklichen. Durch häufige Releases sinkt der Umfang der jeweiligen Änderung und damit das Risiko. Zudem werden durch viele Releases alle Beteiligten geübter im Umgang damit.

  • Zusammenarbeit und Austausch: Entwickler und Administratoren werden aufgefordert und unterstützt, intensiv zusammen zu arbeiten, durch regelmäßige Treffen oder auch Mitarbeit im jeweils anderen Team. Die Administratoren sollen sich mit der Code-Basis vertraut machen und die Entwickler mit den Anforderungen und Prozessen des Betriebs.

    Dabei überschneidet sich der DevOps-Ansatz sicher auch mit dem der Produkt-Teams, bei denen Mitarbeiter aus den verschiedensten Bereichen (vom Fachbereich über’s Marketing bis zur Produktion) zur Entwicklung von Produkten in einem Team dauerhaft zusammenfinden.

    Wie jedoch entsprechende Prozesse oder Ansätze bei DevOps konkret aussehen sollen, wird noch diskutiert. Es gibt verschiedene Ansätze, zum Beispiel die gemeinsame Nutzung von Kanban (siehe zugehörige Yahoo-Gruppe KanbanOps, mehr Beispiele in den Links am Ende dieses Artikels).

  • Flexibel und breit aufgestellt: Entwickler oder Administratoren, die nach DevOps arbeiten, sind multi-disziplinär interessiert und tätig. Von Entwicklungs-Methoden, -Sprachen und -Umgebungen über Monitoring-Anforderungen und -Tools bis hin zu Infrastruktur- und Hardware-Konzepten sollten sie sich überall bis zu einem gewissen Level auskennen, mitdiskutieren und sich bei Bedarf tiefer einarbeiten können.

    Darüber hinaus gehört ein offener und respektierender Umgang miteinander – auch „gute kommunikative Fähigkeiten“ genannt – dazu.

    DevOps taucht mittlerweile auch in Job-Beschreibungen als Anforderung auf, es wird jedoch keine Rolle mit diesem Titel definiert und es soll sie auch nicht geben. Alle Beteiligten sollten DevOps kennen und danach arbeiten.

  • Werkzeuge und Automatisierung: Entwickler und Administratoren sollen gemeinsame Tools nutzen, die den Übergang von der Entwicklung in die Produktion und die Betreuung und Fehlerbehebung vereinfachen (z.B. Puppet oder Chef). Dabei soll so viel wie möglich automatisiert und dadurch eine höhere Release-Frequenz ermöglicht werden.
  • Unterstützung moderner Betriebs-Plattformen: Die im Zusammenhang mit Cloud-Computing bekannt gewordenen und verbreiteten Tools und Konzepte zur Implementierung und Verwaltung von Anwendungen sollen unterstützt und gefördert werden.

Ein umfassendes und konkretes Konzept oder ein grundsätzlich erklärendes Buch bzw. eine entsprechende Veröffentlichung stehen zwar noch aus aber es gärt und dem Zuspruch nach zu urteilen, gibt es viel Bedarf für einen derartige Brücke.

Weiterführende Informationen

Für tiefergehende Informationen zum Thema empfehle ich die folgenden (bis auf eine, allesamt englisch-sprachigen) Quellen:

Vielen Dank an dieser Stelle an Michael Mahlberg, der mich nochmal auf die Relevanz des Themas für meine Arbeit aufmerksam gemacht hat. Und Danke an Matthias Marshall für den ergänzenden Hinweis!

Ich freue mich zudem auf Feedback, Hinweise und Diskussion!

Advertisements
  1. 12. August 2011 um 14:29

    Udo, danke für diese schöne Zusammenstellung und die vielen Links zum Weiterlesen!

  2. 1. Juni 2011 um 09:00

    Vielen Dank für die informative Einführung. Im November letzten Jahres habe ich viele der DevOps-Vordenker eingeladen, Ihre aktuelle Einschätzung zu DevOps abzugeben. Vielleicht wären diese Artikel noch als Ergänzung hilfreich: http://www.agileweboperations.com/devops-series

    • 1. Juni 2011 um 20:18

      Herzlichen Dank Matthias für diesen Hinweis. Ich habe die Artikel-Serie direkt mal verlinkt. Das sind sehr ausführliche und hilfreiche Texte, die das Thema anschaulich und greifbar aus ganz verschiedenen Perspektiven beleuchten. Sehr lesenswert.

      Vielen Dank!

  1. 7. Dezember 2013 um 10:00
  2. 17. November 2011 um 00:01

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: