NetOps adopte Github à l'exception d'un gars qui s'accroche à vimdiff
Et d'autres informations tirées de l' enquête NetDevOps de l'automne 2016 menée par la communauté NetworkToCode
La communauté NetworkToCode est pleine de personnes passionnées par le réseautage et le code. Aussi cliché que cela puisse paraître, ces gens automatisent le réseautage depuis avant même que cela ne devienne cool (et un impératif exécutif).
Au cours de l’automne 2016, la communauté a mené une enquête sur un large éventail de questions axées, de manière appropriée, sur la mise en réseau et le code. Les résultats bruts (liens ci-dessus) sont accessibles au public. La nature des outils d’enquête en ligne est telle que les ensembles de données résultants peuvent être difficiles à analyser à moins de normaliser les données (ce qui demande du travail). Heureusement pour vous, cher lecteur, j’ai fait ce travail pour vous et je peux vous proposer des idées d’une manière plus graphique et colorée.
Les lecteurs astucieux noteront que je prône depuis longtemps l'application de ce que l'on appelle généralement les principes « DevOps » au réseau et, sans surprise, c'est là que j'ai concentré beaucoup d'énergie en explorant ces données.
Il n’est pas surprenant que dans un groupe axé sur le code et le réseautage, les opinions sur DevOps soient au moins majoritairement positives. Seuls 6,75 % n’avaient « aucun intérêt » pour DevOps, tandis que 25,74 % ont indiqué que ce système était déjà en production. La plupart des autres y pensaient au moins (39,24 %), voire n'évaluaient pas (28,27 %).
Les excellents fournisseurs de cette enquête ont posé des questions assez précises sur ce sujet, notamment sur le point de vue de NetOps sur l'infrastructure en tant que code. Cela a suscité un peu plus de désintérêt, avec près de 10 % des personnes interrogées déclarant « aucun intérêt ». Ce qui est intéressant, c'est que seulement 19,35 % ont affirmé que l'infrastructure en tant que code était « déjà en production », mais 54 % des répondants ont indiqué qu'ils utilisaient l'automatisation pour le déploiement de la configuration et 66 % automatisent l'archivage de la configuration. Il existe exactement un NetOps qui automatise la gestion de la configuration (et je suis presque sûr que ce n’est pas le seul NetOps qui utilise fièrement vimdiff pour gérer les changements de configuration).
La première question qui vient généralement à l’esprit est « Qu’est-ce que l’infrastructure en tant que code » ? C’est probablement ce qui explique pourquoi tant de personnes « agissent », même si elles s’identifient principalement comme « évaluant » ou « réfléchissant » à ce sujet. La définition de la fatigue est réelle, les gars , et sans définitions claires fournies de nos jours, il est difficile de tirer des conclusions sur la terminologie éphémère (même si nous le ferons de toute façon, car c'est ce que nous faisons, n'est-ce pas ?).
Alors, qu’est-ce que NetOps automatise ? Nous continuons à leur dire qu’ils doivent le faire pour que le train de la transformation numérique continue de tourner sans retard, mais nous savons aussi que les réseaux d’entreprise, en particulier, ne sont pas exactement un environnement dans lequel on peut jouer avec l’automatisation. Il s’agit de réseaux sérieux, sur lesquels repose aujourd’hui toute l’activité économique. Il s’avère que NetOps automatise beaucoup de choses.
La génération de configuration, l’archivage et le déploiement sont les trois principales opérations automatisées aujourd’hui. La collecte et la communication de données semblent également gagner du terrain.
En fait, à l’exception de la gestion de la configuration (et de celle-là, l’aventureux NetOps), chaque opération semble être automatisée dans un nombre respectable d’organisations interrogées.
Mais bien sûr, l’automatisation des tâches liées à la configuration soulève la question de savoir à quelle fréquence elle se produit et si elle justifie donc l’automatisation ? Je dirais (probablement à l'encontre de la pensée actuelle sur le sujet) que moins vous déployez fréquemment des changements en production, plus l'automatisation est réellement précieuse . Bien sûr, on n’oublie jamais comment faire du vélo, mais avec des mois ou des années entre-temps, ce premier retour en selle peut être une expérience douloureuse (pleine d’erreurs). Il peut en être de même pour les déploiements. Mais c’est un sujet pour un autre jour.
Il s'avère que NetOps est déployé de manière assez régulière, avec environ la moitié (50,92 %) déployant des modifications mineures plus d'une fois par jour dans l'environnement de production, et 37,59 % déployant des modifications majeures 1 à 5 fois par mois. C'est loin des extraordinaires « 200 fois par jour » vantés par les fournisseurs de technologies natives du Web, prenant principalement en charge des applications uniques (pensez à Netflix, PayPal ou Facebook), mais cela permet néanmoins de faire avancer les applications à un rythme assez soutenu pour une entreprise qui prend en charge en moyenne plus de 200 applications (selon nos propres enquêtes sur l'état de la distribution des applications).
Finalement, on se demande comment ils gèrent tous ces changements ? Comme indiqué dans le titre, il y avait vraiment un seul et fier NetOps qui prétend n'utiliser que vimdiff pour gérer les changements. Étant donné la structure des données, il est difficile de corréler cela avec la fréquence des changements dans la production, mais je veux vraiment parler à ce NetOps parce qu’il ou elle est mon héros pour s’accrocher fièrement à ce qui fonctionne pour lui, quelle que soit la pression externe.
Sur quoi s’appuie le reste de NetOps ? Il s’avère que beaucoup d’entre eux utilisent Github. 47% pour être exact. Et un autre groupe important (39 %) utilise du Rancid/Oxidized. Rancid (à ne pas confondre avec le groupe de punk rock américain formé à Berkeley, Californie en 1991) est un outil réseau qui gère les sauvegardes de configuration. Oxidized est également un outil réseau de gestion des sauvegardes de configuration, souvent présenté comme un remplacement de RANCID. Il existe des subreddits qui leur sont dédiés, si vous avez envie d'en savoir plus à leur sujet.
Un chiffre terrifiant de 8 % ne suit pas du tout les changements de configuration. J'ai fait cela une fois en laboratoire et je me suis retrouvé avec une liaison inter-réseaux horriblement asymétrique qui était de 100 Mbps dans un sens et de 1,5 Mbps dans l'autre sens. Oui, j’ai accidentellement recréé le modèle de câble à large bande moderne dans un laboratoire de Green Bay il y a près de 11 ans. Non, je ne reçois pas de royalties, malheureusement, mais la bonne nouvelle est que je ne reçois pas non plus de courrier haineux. Encore une fois, il est difficile de comprendre ce raisonnement sans la capacité de croiser les données en fonction de la taille de l’organisation. Il est intéressant de noter que 11,91 % gèrent entre 0 et 50 périphériques réseau. Il est donc plausible de supposer que ces 8 % ont un nombre gérable de périphériques à gérer et s’en sortent très bien. Le groupe le plus important de NetOps (38,63 %) gère plus de 1 000 appareils, et 28,23 % supplémentaires en gèrent entre 251 et 1 000. Il est donc juste de dire que la majorité des NetOps sont responsables d'un grand nombre d'appareils (presque certainement hétérogènes) et que le suivi des changements de configuration devient donc non seulement nécessaire à la bonne santé continue du réseau, mais également à la santé mentale de ses opérateurs.
D’une manière générale, j’ai vraiment apprécié cette plongée dans le monde de NetDevOps, comme ils se définissent eux-mêmes, et la vue sur ce qu’ils utilisent, ce qu’ils considèrent comme important et à quoi ressemblent les environnements dans lesquels ils opèrent, ne serait-ce que d’un point de vue squelettique à 50 000 pieds.
Les NetOps constituent l'épine dorsale de l'organisation informatique et sont de plus en plus responsables du bon fonctionnement de l'ensemble tandis que les entreprises entreprennent des transformations numériques qui promettent d'augmenter la charge sur le réseau et les opérateurs qui le maintiennent en sécurité.
Je ne crois pas qu’il soit possible de réorganiser complètement les opérations du réseau en passant d’un modèle traditionnel à un modèle plus agile, de type DevOps. Tout comme la transformation numérique des entreprises, la transformation numérique de l’informatique se déroule par étapes, en veillant à ne pas perturber les processus existants qui pourraient faire dérailler le train de l’entreprise. Cette enquête montre qu’une transformation est clairement en cours qui, bien qu’elle ne soit peut-être pas qualifiée de « DevOps » ou qu’elle ne réponde pas entièrement aux notions puristes de ce que cela implique, fait certainement avancer le réseau d’entreprise dans son propre parcours de transformation numérique.