NetOps setzt auf GitHub – bis auf einen Typen, der immer noch an vimdiff festhält

Lori Mac VittieDistinguished Engineer und Chief Evangelist | F5

Und weitere Erkenntnisse aus der NetDevOps-Umfrage vom Herbst 2016 der NetworkToCode-Community

Die NetworkToCode-Community ist voller Menschen, die sich für Netzwerke und Code begeistern. So klischeehaft das auch klingen mag: Diese Leute automatisieren Netzwerke schon seit einer Zeit, als das noch lange nicht als cool galt (und auch noch keine Vorgabe der Geschäftsleitung war).

Im Herbst 2016 führte die Community eine Umfrage mit einem breiten Spektrum an Fragen durch, die sich passenderweise auf Netzwerktechnik und Code konzentrierten. Die Rohdaten der Ergebnisse (oben verlinkt) sind öffentlich zugänglich. Online-Umfragetools bringen es mit sich, dass die daraus resultierenden Datensätze nur schwer zu analysieren sind, wenn die Daten nicht normalisiert werden (was einigen Aufwand erfordert). Zum Glück für Sie, liebe Leserinnen und Leser, habe ich Ihnen diese Arbeit abgenommen und kann die gewonnenen Erkenntnisse anschaulicher und farbenfroher präsentieren.

Aufmerksame Leser werden feststellen, dass ich mich schon seit Langem dafür einsetze, die üblicherweise als „DevOps“-Prinzipien auf das Netzwerk zu übertragen. Daher überrascht es nicht, dass ich mich bei der Analyse dieser Daten intensiv damit beschäftigt habe.

Es überrascht nicht, dass die Einstellung zu DevOps in einer Gruppe, die sich auf Code und Netzwerke konzentriert, überwiegend positiv war. Nur 6,75 % hatten „kein Interesse“ an DevOps, während 25,74 % angaben, DevOps bereits produktiv einzusetzen. Die meisten anderen dachten zumindest darüber nach (39,24 %) oder evaluierten es bereits (28,27 %).

Die geschätzten Initiatoren dieser Umfrage stellten einige recht detaillierte Fragen zu diesem Thema, unter anderem zur Sichtweise von NetOps auf Infrastructure as Code. Hier war das Desinteresse etwas größer: Fast 10 % gaben an, „kein Interesse“ zu haben. Interessant war, dass nur 19,35 % angaben, Infrastructure as Code sei „bereits im Produktiveinsatz“, während ganze 54 % der Befragten erklärten, Automatisierung für die Bereitstellung von Konfigurationen einzusetzen, und weitere 66 % die Archivierung von Konfigurationen automatisieren. Genau ein NetOps automatisiert das Konfigurationsmanagement (und ich bin mir ziemlich sicher, dass es nicht derjenige ist, der voller Stolz vimdiff zur Verwaltung von Konfigurationsänderungen verwendet).

Die erste Frage, die einem normalerweise in den Sinn kommt, lautet ohnehin: „Was ist Infrastructure as Code?“ Das ist wahrscheinlich der Hauptgrund dafür, dass so viele mehr es bereits „praktizieren“, obwohl sie sich selbst eher als „in der Evaluierungsphase“ oder „noch in der Überlegungsphase“ einstufen. Definitionsmüdigkeit gibt es wirklich, Leute, und da heutzutage keine klaren Definitionen vorgegeben werden, ist es schwierig, aus kurzlebigen Begrifflichkeiten Schlüsse zu ziehen (obwohl wir es trotzdem tun werden, denn genau das machen wir doch, oder?).

Was also automatisiert NetOps eigentlich? Wir sagen ihnen immer wieder, dass sie automatisieren müssen, damit die digitale Transformation ohne Verzögerungen vorankommt. Gleichzeitig wissen wir aber auch, dass insbesondere Unternehmensnetzwerke nicht gerade eine Umgebung sind, in der man einfach mit Automatisierung herumexperimentiert. Es handelt sich um geschäftskritische Netzwerke, von denen heute das gesamte Unternehmen abhängt. Wie sich zeigt, automatisiert NetOps bereits eine ganze Menge.

Die Erstellung, Archivierung und Bereitstellung von Konfigurationen sind derzeit die drei am häufigsten automatisierten Vorgänge. Auch die Datenerfassung und Berichterstellung scheinen zunehmend an Bedeutung zu gewinnen.

Tatsächlich scheint mit Ausnahme des Konfigurationsmanagements (und jenes einen abenteuerlustigen NetOps-Teams) jeder Vorgang in einer beachtlichen Zahl der Unternehmen der Befragten automatisiert zu sein.

Doch natürlich wirft die Automatisierung konfigurationsbezogener Aufgaben die Frage auf, wie häufig diese anfallen und ob sich ihre Automatisierung daher lohnt. Ich würde behaupten (und widerspreche damit wahrscheinlich der derzeit vorherrschenden Meinung zu diesem Thema): Je seltener Sie Änderungen in die Produktionsumgebung überführen, desto wertvoller ist die Automatisierung tatsächlich. Natürlich „verlernt“ man das Fahrradfahren nie, doch wenn Monate oder Jahre dazwischenliegen, kann die erste Fahrt zurück im Sattel sozusagen zu einer schmerzhaften (und fehlerbehafteten) Erfahrung werden. Genauso kann es sich mit Bereitstellungen verhalten. Aber das ist ein Thema für einen anderen Tag.

Wie sich zeigt, führt NetOps ziemlich regelmäßig Deployments durch: Knapp die Hälfte (50,92 %) spielt kleinere Änderungen mehrmals täglich in die Produktionsumgebung ein, während 37,59 % größere Änderungen ein- bis fünfmal pro Monat bereitstellen. Das reicht zwar bei Weitem nicht an die außergewöhnlichen „200 Deployments pro Tag“ heran, mit denen webnative Technologieanbieter werben, die in erster Linie eine einzelne Anwendung betreiben (etwa Netflix, PayPal oder Facebook). Für ein Unternehmen, das im Durchschnitt mehr als 200 Anwendungen unterstützt (laut unseren eigenen „State of Application Delivery“-Umfragen), werden Anwendungen damit aber dennoch in einem beachtlichen Tempo weiterentwickelt.

Abschließend stellt sich die Frage, wie all diese Änderungen verwaltet werden. Wie bereits im Titel erwähnt, gab es tatsächlich eine einzelne, stolze NetOps-Fachkraft, die angab, Änderungen ausschließlich mit vimdiff zu verwalten. Aufgrund der Datenstruktur lässt sich dies nur schwer mit der Häufigkeit von Änderungen in der Produktionsumgebung in Zusammenhang bringen. Dennoch würde ich mich sehr gern mit dieser Person unterhalten, denn sie ist mein Vorbild: Sie hält stolz an dem fest, was für sie funktioniert – ungeachtet des Drucks von außen.

Worauf verlassen sich die übrigen NetOps? Wie sich herausstellt, nutzen sehr viele von ihnen Github – genauer gesagt 47 %. Eine weitere große Gruppe (39 %) verwendet Rancid/Oxidized. Rancid (nicht zu verwechseln mit der 1991 in Berkeley, Kalifornien, gegründeten amerikanischen Punkrockband) ist ein Netzwerktool zur Verwaltung von Konfigurationssicherungen. Oxidized ist ebenfalls ein Netzwerktool zur Verwaltung von Konfigurationssicherungen und wird häufig als Ersatz für RANCID angepriesen. Falls Sie mehr darüber erfahren möchten, gibt es eigene Subreddits dazu.

Erschreckende 8 % verfolgen Konfigurationsänderungen überhaupt nicht. Das habe ich einmal im Labor gemacht und hatte am Ende eine furchtbar asymmetrische netzwerkübergreifende Verbindung, die in eine Richtung 100 Mbit/s und in die andere 1,5 Mbit/s erreichte. Ja, ich habe vor fast 11 Jahren in einem Labor in Green Bay versehentlich das moderne Breitbandkabelmodell nachgebildet. Nein, leider bekomme ich dafür keine Tantiemen – aber die gute Nachricht ist, dass ich auch keine Hassmails erhalte. Auch hier lässt sich diese Entscheidung nur schwer nachvollziehen, solange keine Kreuztabellierung nach Unternehmensgröße möglich ist. Interessanterweise verwalten 11,91 % zwischen 0 und 50 Netzwerkgeräte. Daher liegt die Vermutung nahe, dass diese 8 % eine überschaubare Anzahl von Geräten verwalten und damit gut zurechtkommen. Die größte NetOps-Gruppe (38,63 %) verwaltet mehr als 1.000 Geräte, weitere 28,23 % verwalten zwischen 251 und 1.000. Man kann also mit Fug und Recht behaupten, dass die Mehrheit der NetOps für eine große Zahl von Geräten verantwortlich ist, die mit ziemlicher Sicherheit heterogen sind. Die Nachverfolgung von Konfigurationsänderungen ist daher nicht nur für den dauerhaft reibungslosen Betrieb des Netzwerks unerlässlich, sondern auch für die geistige Gesundheit derjenigen, die es betreiben.

Alles in allem hat mir dieser Einblick in die Welt von NetDevOps, wie sie sich selbst nennen, sehr gut gefallen. Er vermittelt einen Eindruck davon, welche Tools sie einsetzen, was sie für wichtig halten und wie die Umgebungen aussehen, in denen sie arbeiten – wenn auch nur als grober Überblick aus der Vogelperspektive.

NetOps bilden das Rückgrat der IT-Organisation und tragen zunehmend die Verantwortung dafür, dass alles reibungslos funktioniert, während Unternehmen digitale Transformationen vorantreiben, die das Netzwerk und die für seinen sicheren Betrieb zuständigen Fachkräfte voraussichtlich noch stärker belasten werden.

Ich glaube nicht, dass es möglich ist, den Netzwerkbetrieb auf einen Schlag von einem traditionellen Modell auf ein agileres, DevOps-ähnliches Modell umzustellen. Wie die digitale Transformation des Unternehmens erfolgt auch die digitale Transformation der IT schrittweise und mit dem Ziel, bestehende Prozesse nicht zu beeinträchtigen, da dies den Geschäftsbetrieb aus der Spur bringen könnte. Diese Umfrage zeigt deutlich, dass ein Wandel stattfindet, der zwar vielleicht nicht als „DevOps“ bezeichnet wird oder die Vorstellungen von Puristen darüber, was dies beinhaltet, nicht vollständig erfüllt, das Unternehmensnetzwerk auf seinem eigenen Weg der digitalen Transformation aber definitiv voranbringt.

Ü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