Fragen über Fragen

„Lasst uns mal schnell agil werden und unsere Produkte schneller auf den Markt werfen“ – so oder ähnlich denken viele Unternehmen. DevOps scheint momentan als eine Art Wunderwaffe angesehen zu werden. Doch ganz so einfach ist es nicht. Zunächst sollten sich Unternehmen darüber klar werden, welches Problem sie mit DevOps eigentlich lösen möchten, so der Rat von PwC. Ein fundierter Beweggrund sei das A und O, um eventuell auftretende Startschwierigkeiten zu vermeiden und alle Beteiligten zu überzeugen.

Sehr häufig wird DevOps vorrangig genutzt, um die Effizienz der IT zu erhöhen. Das ist jedoch zu kurz gedacht: Oberstes Ziel sollte sein, die Effizienz des gesamten Unternehmens zu steigern, indem Marktanforderungen frühzeitig erkannt und Kundenbedürfnisse erfüllt werden.

Der DevOps-Ansatz ist ideal, wenn es zum Beispiel da­rum geht, auf Software basierende Business-Prozesse schnell in die Praxis zu bringen. Wichtig sind Anpassungen sowohl in der Organisatio, etwa flache Hierarchien, als auch bei den Verantwortlichkeiten für den Roll-out eines Software-Produkts oder eines Dienstes. „Die Technologie ist im Zusammenspiel mit der Software-Entwicklung die Basis, damit dies möglich ist. Aktuell liegt ein Fokus auf den Betriebskosten. Hier verspricht DevOps ein Modell zu sein, das hilft, Kosten einzusparen“, so Frank Haumann von Red Reply. Dies gelte insbesondere dann, wenn man versucht, Kostenreduktionen im Bereich Operations zu realisieren, „in dem die Entwickler gemäß des Leitsatzes ,You build it, you run it‘ auch Verantwortung für den Betrieb der erstellten Lösung liefern“.

Übrigens: Die in vielen Unternehmen nach wie vor eingesetzten Legacy-Strukturen sind kein Hindernis für den DevOps-Ansatz, auch wenn im DevOps-Zusammenhang häufig von modernen Infrastrukturen wie der Cloud die Rede ist. „DevOps lässt sich auch für Legacy-Strukturen einsetzen“, ist Frank Haumann überzeugt, „weil es eine Kultur ist, die auf jede Art von Technik angewendet werden kann.“ Schwierig bis unmöglich werde es jedoch, eine DevOps-Kultur in stark regulierten Umfeldern wie der Gesundheitsbranche, dem Luftfahrtsektor oder in der Finanzindustrie einzuführen – „in diesen Bereichen bestehen oft sehr strikte Regularien, die von diversen Behörden überwacht werden.“

Nichtsdestotrotz wird DevOps – und vor allem das eingangs erwähnte SRE – häufig mit neuen Technologien wie Cloud, Containern und Microservice-Architekturen in Verbindung gebracht. Doch der fundamentale Ansatz hinter DevOps ist Vassil Hristov zufolge unabhängig von den Tools und dem Technologie-Stack. Er teilt die Meinung von Frank Haumann und sagt, dass „nichts dagegen spricht, auch bei Legacy-Systemen die Prozesse so umzustellen, dass die Verantwortung von Entwicklung und Betrieb von Software besser verteilt ist, Silos abgebaut werden und ein erhöhter Automatisierungsgrad gefördert wird“. Als Beispiel nennt er Gitlab und IBM, die an einer DevOps-Lösung für Mainframe-Entwickler arbeiten. „Das zeigt, dass der Ansatz durchaus auch bei Legacy-Technologien angewendet werden kann.“

Es gibt aber durchaus auch Felder, in denen der DevOps-Ansatz wenig sinnvoll ist. DevOps ist zum Beispiel nicht notwendig, wenn es keine oder nur langsame und vorhersehbare Veränderungen gibt. Das ist mitunter in manchen Behörden, im Bildungssektor, bei klassischen Software-Produkten, etwa im Office-Bereich,  oder auch in der Lebensmittelbranche der Fall. Komplexe und schnell zu verändernde Produkte, wie große Konzerne sie entwickeln oder einsetzen, erfordern jedoch DevOps. Denn hier geht der Erfolgsweg für Software-Releases oder Produkt-Releases nur über Trial und Error.

Ein weiteres Beispiel wäre Software, die beim Kunden vor Ort installiert ist – die also nicht zentral in der Cloud oder in wenigen Instanzen läuft. Bei einem Produkt, das beim Kunden installiert wird, braucht man natürlich viel mehr Ressourcen für den Betrieb der Software, gegebenenfalls auch für verschiedene Plattformen und verschiedene Versionen des Produkts. Ein kleines Team dürfte nicht in der Lage sein, die Software zu entwickeln und sie gleichzeitig auf Hunderten heterogenen Kundensystemen zu betreiben.