Et d’autres enseignements tirés de l’enquête NetDevOps de l’automne 2016 menée par la communauté NetworkToCode community
La communauté NetworkToCode regorge de passionnés des réseaux et du code. Aussi cliché que cela puisse paraître, ces personnes automatisent les réseaux depuis bien avant que cela ne devienne tendance (et une priorité pour les dirigeants).
À l’automne 2016, la communauté a mené une enquête comportant un large éventail de questions portant, comme il se doit, sur les réseaux et le code. Les résultats bruts (accessibles via le lien ci-dessus) sont disponibles publiquement. Les outils d’enquête en ligne produisent souvent des jeux de données difficiles à analyser sans normalisation préalable, ce qui demande du travail. Heureusement pour vous, cher lecteur, je m’en suis chargé et peux ainsi vous présenter les enseignements tirés sous une forme plus graphique et plus colorée.
Les lecteurs avisés remarqueront que je préconise depuis longtemps d’appliquer au réseau ce que l’on appelle généralement les principes « DevOps » ; c’est donc sans surprise sur cet aspect que j’ai concentré une grande partie de mes efforts en analysant ces données.
Il n’est guère surprenant que, dans un groupe axé sur le code et les réseaux, les avis sur le DevOps aient été majoritairement positifs. Seuls 6,75 % des répondants ne manifestaient « aucun intérêt » pour le DevOps, tandis que 25,74 % indiquaient l’avoir déjà déployé en production. La plupart des autres envisageaient au moins de l’adopter (39,24 %), voire étaient en train de l’évaluer (28,27 %).
Les excellents auteurs de cette enquête ont posé des questions assez pointues sur le sujet, notamment sur le point de vue des NetOps concernant l’infrastructure en tant que code. Celle-ci a suscité un peu plus de désintérêt, près de 10 % des répondants déclarant ne pas être intéressés. Fait intéressant, seuls 19,35 % ont affirmé que l’infrastructure en tant que code était « déjà en production », alors que pas moins de 54 % des répondants ont indiqué utiliser l’automatisation pour déployer les configurations et que 66 % automatisent leur archivage. Un seul NetOps automatise la gestion des configurations (et je suis presque certain que ce n’est pas celui qui se vante d’utiliser vimdiff pour gérer les modifications de configuration).
La première question qui vient généralement à l’esprit est : « Mais au fait, qu’est-ce que l’Infrastructure as Code ? » C’est probablement ce qui explique pourquoi tant de personnes en « font » alors qu’elles déclarent surtout être en train de l’« évaluer » ou d’y « réfléchir ». La lassitude face aux définitions existe bel et bien, les amis, et comme il est aujourd’hui rare de disposer de définitions claires, il est difficile de tirer des conclusions sur une terminologie éphémère (même si nous allons quand même le faire, parce que c’est ce que nous faisons, n’est-ce pas ?).
Alors, qu’est-ce que les NetOps automatisent ? Nous ne cessons de leur répéter qu’ils doivent le faire pour que la transformation numérique poursuive son chemin sans encombre, mais nous savons aussi que les réseaux d’entreprise, en particulier, ne sont pas vraiment un environnement où l’on peut s’amuser à expérimenter l’automatisation. Ce sont des réseaux critiques, dont dépend aujourd’hui toute l’entreprise. Il s’avère que les NetOps automatisent beaucoup de choses.
La génération, l’archivage et le déploiement des configurations sont aujourd’hui les trois principales opérations automatisées. La collecte de données et la création de rapports semblent également gagner du terrain.
En fait, à l’exception de la gestion des configurations (et de ce NetOps aventureux), toutes les opérations semblent être automatisées dans un nombre non négligeable d’organisations ayant répondu à l’enquête.
Mais bien sûr, l’automatisation des tâches liées à la configuration soulève une question : à quelle fréquence sont-elles effectuées et cette fréquence justifie-t-elle donc leur automatisation ? Je dirais (probablement à contre-courant de l’opinion actuelle sur le sujet) que moins vous déployez fréquemment des changements en production, plus l’automatisation est précieuse en réalité. Certes, on n’« oublie » jamais comment faire du vélo, mais lorsqu’on ne remonte en selle qu’après plusieurs mois ou années, cette première reprise peut être une expérience pénible (et truffée d’erreurs). Il peut en aller de même pour les déploiements. Mais c’est un sujet pour une autre fois.
Il s’avère que les équipes NetOps effectuent des déploiements assez régulièrement : près de la moitié (50,92 %) déploient des changements mineurs dans l’environnement de production plus d’une fois par jour, tandis que 37,59 % y déploient des changements majeurs une à cinq fois par mois. On est loin des extraordinaires « 200 fois par jour » dont se targuent les fournisseurs de technologies nés sur le Web et prenant principalement en charge une seule application (comme Netflix, PayPal ou Facebook), mais le rythme de déploiement des applications reste soutenu pour une entreprise qui en gère en moyenne plus de 200 (selon nos propres enquêtes sur l’état de la mise à disposition des applications).
Enfin, on peut se demander comment ils gèrent tous ces changements. Comme l’indique le titre, il y avait bel et bien un ou une spécialiste NetOps qui affirmait fièrement n’utiliser que vimdiff pour gérer les changements. Compte tenu de la structure des données, il est difficile d’établir un lien avec la fréquence des changements en production, mais j’aimerais vraiment parler à cette personne, car elle est mon héroïne pour continuer à défendre fièrement ce qui fonctionne pour elle, malgré les pressions extérieures.
Sur quoi s’appuient les autres NetOps ? Il s’avère qu’un très grand nombre d’entre eux utilisent Github : 47 % pour être exact. Un autre groupe important (39 %) utilise Rancid/Oxidized. Rancid (à ne pas confondre avec le groupe de punk rock américain formé à Berkeley, en Californie, en 1991) est un outil réseau qui gère les sauvegardes de configuration. Oxidized est lui aussi un outil réseau de gestion des sauvegardes de configuration, souvent présenté comme une solution de remplacement de RANCID. Des subreddits leur sont consacrés, si l’envie vous prend d’en apprendre davantage à leur sujet.
Fait inquiétant, 8 % ne suivent absolument pas les modifications de configuration. Je l’ai fait une fois en laboratoire et je me suis retrouvé avec une liaison interréseau terriblement asymétrique, offrant 100 Mbit/s dans un sens et 1,5 Mbit/s dans l’autre. Oui, j’ai accidentellement recréé le modèle moderne de l’Internet haut débit par câble dans un laboratoire de Green Bay il y a près de 11 ans. Non, malheureusement, je ne touche aucune redevance, mais la bonne nouvelle, c’est que je ne reçois pas non plus de courrier haineux. Là encore, il est difficile de comprendre ce choix sans pouvoir croiser les données avec la taille de l’organisation. Fait intéressant, 11,91 % gèrent entre 0 et 50 équipements réseau ; on peut donc raisonnablement supposer que ces 8 % ont un nombre raisonnable d’équipements à gérer et s’en sortent très bien. Le groupe le plus important de professionnels NetOps (38,63 %) gère plus de 1 000 équipements, tandis que 28,23 % supplémentaires en gèrent entre 251 et 1 000. On peut donc affirmer que la majorité des professionnels NetOps sont responsables d’un grand nombre d’équipements (presque certainement hétérogènes) et que le suivi des modifications de configuration devient dès lors indispensable non seulement au bon fonctionnement durable du réseau, mais aussi à la santé mentale de ses opérateurs.
Dans l’ensemble, j’ai vraiment apprécié cette immersion dans l’univers du NetDevOps, comme ses adeptes le désignent eux-mêmes, ainsi que cet aperçu des outils qu’ils utilisent, de ce qu’ils jugent important et des environnements dans lesquels ils évoluent, même s’il ne s’agit que d’une vue d’ensemble très sommaire.
Les équipes NetOps constituent la colonne vertébrale de l’organisation informatique et sont de plus en plus chargées de veiller au bon fonctionnement de l’ensemble des systèmes, tandis que les entreprises entreprennent des transformations numériques qui risquent d’alourdir la charge pesant sur le réseau et sur les opérateurs qui en assurent le fonctionnement sécurisé.
Je ne pense pas qu’il soit possible de remanier entièrement les opérations réseau pour passer d’un modèle traditionnel à un modèle plus agile, proche du DevOps. À l’instar de la transformation numérique des entreprises, celle de l’informatique s’effectue par étapes, en veillant à ne pas perturber les processus existants qui pourraient faire dérailler l’activité. Cette enquête montre clairement qu’une transformation est en cours. Même si elle n’est peut-être pas qualifiée de « DevOps » et ne répond pas totalement à la conception qu’en ont les puristes, elle fait indéniablement progresser le réseau d’entreprise dans son propre parcours de transformation numérique.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.