In der heutigen IT-Welt lässt sich der Begriff DevOps an vielen Stellen finden – er wird gerade plakativ eingesetzt. Sei es in der Stellenbeschreibung oder als Oberbegriff bei Cloud-Komponenten. Die Spannweite reicht von DevOps Engineer bis DevOps as a Service.

Aber was ist DevOps denn eigentlich?

Geht man pragmatisch an die Fragestellung heran und wirft einen Blick auf Wikipedia, findet man folgende Definition:

“DevOps beschreibt einen Ansatz, wie die Zusammenarbeit zwischen Softwareentwicklung und IT-Betrieb verbessert werden kann. DevOps soll durch gemeinsame Anreize, Prozesse und Software-Werkzeuge (engl. tools) eine effektivere und effizientere Zusammenarbeit der Bereiche Dev, Ops, Qualitätssicherung (QS) und Fachbereichen ermöglichen. Mit DevOps sollen die Qualität der Software, die Geschwindigkeit der Entwicklung und der Auslieferung sowie das Miteinander der beteiligten Teams verbessert werden.”
– Wikipedia

DevOps soll also “[…] die Zusammenarbeit zwischen Softwareentwicklung und IT-Betrieb […]” verbessern, dabei sollen Werkzeuge eingesetzt und Prozesse optimiert werden. So wie damals schon oft Mauern eingeschlagen wurden, soll dies auch hier passieren. Das bedeutet im Umkehrschluss, beide Seiten müssen sich verändern. Die Entwicklung soll nun nicht mehr die zu installierende Software über den Zaun werfen und die Administration sich nicht mehr durch eine Mauer vor der Entwicklung abschotten.

Daraus resultieren zwei Betrachtungsweisen auf DevOps, der aus dem “Development” und der aus “Operations”. Die Entwicklung betrachtet die Software von der operativen Seite und es treten Fragen auf: Wie komme ich einheitlich an Informationen meiner Services, um Fehleranalysen zu betreiben? Wie kann ich die “Installation” der Software einfacher gestalten? Die operative Seite stellt sich Fragen wie: Kann ich die Infrastruktur transparenter gestalten und zugänglicher für die Entwicklung machen?

Auf beiden Seiten kommen Automatisierungen ins Spiel. Sei es zum Testen, Bereitstellung von Infrastruktur oder Konfigurationsmanagement. Prozesse werden eingeführt um möglichst viele Dinge nicht mehr manuell durchführen zu müssen. Das Releasen von Software oder der gesamte Aufbau einer Infrastruktur. Dadurch wird auch der große Zuwachs von Cloud Anbietern verständlich. Die Abstraktion durch den Kauf von Rechenleistung mit nur wenigen Mausklicks, ohne dass man selbst im Besitz eines Serverraums oder Rechenzentrums ist. Über API Schnittstellen lassen sich ganze Server Landschaften auf der ganzen Welt erstellen und im Nu wieder abstoßen.

Die Tools dafür wachsen immer weiter an. Das Portfolio von DevOps erschließt sich nun von einfachen “Automatisierungssprachen” bis hin zur Agilen DevOps Transformation und Prozessoptimierung. Hier setzt die “DevOps” Rolle im Projekt an, um Denkanstöße und Realisierungen gemeinsam mit allen Beteiligten umzusetzen. Nicht nur bei Entwicklern und Administratoren, sondern auch über den Product Owner und Architekten bis hin zum CEO.

DevOps hat seinen Ursprung in der Welt der IT, ist Vorreiter der Agilen-Methoden und flachen Hierarchien. Nichts desto weniger können außenstehende Faktoren wie Architekturgestaltung oder Produktentscheidungen der Software Qualität und “DevOps” im Wege stehen. Sei es durch klassische starre Organisationsstrukturen oder Prozesse. Auch aus finanzieller Sicht ist DevOps immer erst ein Invest mit wenig visueller Auswirkung. Der Vorteil zeigt sich hier nicht direkt. Durch die Optimierung von Prozessen und Automatisierung verschaffen sich beiden Seiten einen freieren Handlungsspielraum. Das Ziel ist es, die Operational Excellence zu steigern. Durch diese kontinuierliche Veränderung des Projektes entwickelt sich DevOps im Projekt auch stetig weiter.

Aber wo endet DevOps nun für mich? Ist DevOps etwas, was sich nur in der Welt der Softwareentwicklung und IT wiederfinden kann?
Für mich bedeutet DevOps das Einreißen von Mauern und das Bauen von Brücken, um “Unannehmlichkeiten” zu reduzieren oder sogar zu beseitigen. DevOps kann man für mich überall zwischen zwei zusammenarbeitenden Parteien anwenden. Im Kern ist es einfach nur das Verständnis dem anderen gegenüber? Die Herausforderung ist zu verstehen, dass man durch seine Arbeit es erst anderen leichter macht. Dadurch wird die eigene Arbeit erleichtert. Es ist wie mit dem Wissen, dass sich verdoppelt, indem man es teilt.