Drei Dinge, die Sie davon abhalten, DevOps einzuführen

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Nein, nicht Sie. Sie. Führungskräfte sind von DevOps längst nicht so begeistert wie diejenigen, die direkt damit arbeiten. Der Grund dafür könnte in einem dieser drei zentralen Bedenken liegen.

Leistungsstarke Unternehmen haben DevOps nicht nur eingeführt, sondern leben es auch. Der wegweisende „State of DevOps“-Bericht von Puppet Labs hat uns dies in den vergangenen zwei Jahren gezeigt, und ich gehe davon aus, dass er diesen Zusammenhang im kommenden Jahr erneut bestätigen wird. Laut einer Reihe von Branchenumfragen und Studien führen Unternehmen DevOps ein. Doch genau wie bei der früheren Einführung agiler, schlanker Methoden zur Anwendungsentwicklung bedeutet „Einführung“ nicht immer das, was wir darunter verstehen. Es stellte sich heraus, dass Unternehmen mit der „Einführung agiler Methoden“ in der Anwendungsentwicklung tatsächlich meinten, dass nur ein relativ kleiner Prozentsatz ihrer Projekte agile Methoden nutzte. Es bedeutete nicht, dass sie aufs Ganze gegangen waren und den Sprung ins kalte Wasser gewagt hatten, indem sie diese Methoden bei jedem Projekt einsetzten.

Dasselbe scheint für DevOps zu gelten: Die Befragten setzen den Ansatz mit Begeisterung um – und erzielen Ergebnisse –, doch die Führungskräfte insgesamt scheinen ihm gegenüber nach wie vor eher zurückhaltend zu sein. Der „strategische Einfluss“ stieg im Jahresvergleich lediglich um zwei Prozentpunkte – von 15 % im Jahr 2016 auf 17 % im Jahr 2017, wie unsere Umfrage State of Application Delivery zeigt. Während Cloud-Architekten und Personen, die ihre Rolle selbst dem Bereich „DevOps“ zuordnen, ihre DevOps-Initiative möglicherweise mit voller Kraft vorantreiben und sogar bereits in die Produktion überführt haben, hinken die Führungskräfte bei der Akzeptanz des Ansatzes weiterhin hinterher. Das bedeutet letztlich, dass „Unternehmen“ DevOps nicht unbedingt voll und ganz unterstützen.

Es gibt drei zentrale Bedenken, die wahrscheinlich dafür verantwortlich sind, dass die IT- und Unternehmensführung DevOps nicht die herzliche Aufnahme bereitet, die es wirklich verdient.

1. Zeit. Interne IT-Projekte jeglicher Art, die ein Umdenken im Sinne einer Migration erfordern – ob von traditionellen Systemen in die Cloud, von monolithischen Architekturen zu Microservices oder von manuellen zu automatisierten Prozessen –, werden mitunter lediglich als Zeitverschwendung betrachtet. Sie tragen nicht unmittelbar zum Unternehmenswachstum bei, weshalb es für geschäftliche Entscheidungsträger schwierig sein kann, den Zeitaufwand für solche Projekte zu rechtfertigen. Befürworter von DevOps sollten der Unternehmensleitung daher klare Ziele und die erwarteten Vorteile solcher Projekte aufzeigen. Ob Kosteneinsparungen oder eine reaktionsfähigere IT: Das Unternehmen muss die erwartete Rendite der Investition verstehen, damit es das Vorhaben mitträgt und unterstützt. Ein gesparter Cent mag ein verdienter Cent sein, doch ein investierter Cent bringt oft zehn Cent ein. Unternehmen, die jetzt in DevOps investieren, werden später davon profitieren.
   
2. Beeinträchtigung. Kein IT-Verantwortlicher möchte Betriebsstörungen verursachen. Jetzt in eine DevOps-Initiative zu investieren, kann Beeinträchtigungen mit sich bringen – insbesondere, wenn dadurch die Produktionspipeline verlangsamt wird, obwohl allen klar ist, dass sie eigentlich beschleunigt werden muss. Da die Vorbereitung der Produktionsumgebung auf Automatisierung und Orchestrierung häufig Eingriffe in die für das Tagesgeschäft verantwortlichen Systeme erfordert, kann jede entsprechende Initiative unerwünschte Störungen verursachen. Tatsächlich könnte jedoch das Festhalten an veralteten, manuellen Methoden zur Bereitstellung, Skalierung und Verwaltung von Systemen die eigentliche Störung darstellen – wenn nicht heute, dann morgen. Ein Kennzeichen einer reibungslosen Produktionsumgebung ist die Fähigkeit, bei Bedarf auf Anforderungen an Kapazitäten und Services zu reagieren. Dies wird zunehmend schwieriger, da die IT unter der Last der wachsenden Nachfrage infolge der digitalen Transformation ächzt. Ohne Risiko kein Gewinn. Das Risiko jetzt einzugehen, ist wahrscheinlich weniger riskant, als zu warten, bis Ihr Anwendungsportfolio auf das Doppelte oder mehr angewachsen ist.
   
3. Anbieterbindung. Eine häufige Sorge von IT-Führungskräften besteht darin, sich durch Entscheidungen an einen Anbieter zu binden. Die gute Nachricht ist, dass die meisten Netzwerkgeräte und Systeme, die Automatisierung und Orchestrierung unterstützen, auf offenen Standardprotokollen und Konzepten wie HTTP, REST und JSON basieren. Hier zahlt sich die Zeit, die vorab in die Konzeption und Architektur eines Systems investiert wird, das APIs und Vorlagen so weit wie möglich nutzt, später aus. Die Integration von Geräten oder Systemen, bei denen über eine API schrittweise per CLI ausgeführte Befehle nachgebildet werden müssen, führt mit ziemlicher Sicherheit zu einer Anbieterbindung. Darin liegt einer der größten Vorteile von Vorlagen: Sie verringern die Abhängigkeit von geräte- und systemspezifischen APIs und beschränken diese auf wenige Befehle, die sich künftig problemlos auf ein neues System oder eine neue Anwendung übertragen lassen. Stellen Sie sicher, dass die Infrastruktur eine REST-basierte API unterstützt, und verwenden Sie nach Möglichkeit Vorlagen, damit sich Daten später problemlos aus Systemen und Umgebungen extrahieren lassen.

Natürlich gibt es noch weitere Bedenken, doch bei der Einführung neuer Technologien und Methoden sind es vor allem diese drei zentralen Aspekte, die in Rechenzentren seit jeher zur Sprache kommen: Es braucht Zeit, kann den laufenden Betrieb beeinträchtigen und birgt ein erhebliches Risiko der Anbieterbindung. Mit der gebotenen Sorgfalt, einem durchdachten Implementierungsansatz und der Einstellung, heute zu investieren, um später davon zu profitieren, lassen sich diese Bedenken ausräumen. Zugleich steigen so die Chancen, erfolgreich ein solides und dennoch flexibles Fundament zu schaffen, das die für das heutige und künftige Unternehmenswachstum notwendige digitale Transformation nicht nur ermöglicht, sondern beschleunigt.

Über den Autor

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Lori MacVittie ist Distinguished Engineer und Chief Evangelist im Office of the CTO von F5 und verfügt über umfassende Expertise in den Bereichen Anwendungsbereitstellung, Automatisierungsstrategie und Infrastruktur. Sie ist dafür bekannt, Komplexität verständlich zu machen – ob sie Leitplanken für KI-Agenten definiert, fragile Multicloud-Architekturen analysiert oder die Grenzen skalierbarer Systeme auslotet. Sie verfügt über mehr als dreißig Jahre Branchenerfahrung in der Anwendungsentwicklung, IT-Architektur sowie im Netzwerk- und Systembetrieb. Bevor sie zu F5 kam, war sie als mehrfach ausgezeichnete Technologie-Redakteurin tätig. MacVittie hat einen Masterabschluss in Informatik und ist eine produktive Autorin, deren Veröffentlichungen die Bereiche Sicherheit, Cloud und Unternehmensarchitektur abdecken. Außerdem spielt sie leidenschaftlich gern Brett- und Videospiele und vertritt mit voller Überzeugung klare Ansichten zum Thema Käse.

Weitere Blogbeiträge von Lori Mac Vittie