Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Standardisation : pourquoi les NetOps doivent apprendre des DevOps

mars 2019 par Lorie MacVittie, chercheur en cyber-menaces, F5 Networks

Les standards sont parfois vus comme l’antithèse de l’innovation.
Et cela peut se comprendre : après tout, abandonner un buffet à volonté
(autrement dit, une infinité de pratiques) pour se limiter à un menu fixe (un
nombre réduit de pratiques standardisées) n’est pas une proposition très
attrayante à première vue. Sans compter que les standards sont généralement
associés au monde austère de conformité, et que celui-ci ne fait pas franchement
chavirer les foules… Car les standards ont des noms très officiels tels que ISO
8076.905E et débordent de cases à cocher, d’auditeurs et de comités de
contrôle : absolument rien qui ne puisse encourager la créativité.

Mais quand on pense innovation, et, en particulier d’innovation par le code, on
réalise que tout cela n’existe pas : il n’y a aucun standard officiel qui ne
régisse le choix des entreprises en matière de langages de programmation, de
frameworks de développement ou de protocoles à implémenter dans tel ou tel cas.

Sur le terrain le choix se fait donc plutôt en fonction de considérations très
pratiques telles que la disponibilité des talents, la capacité à supporter le
projet, et bien entendu le coût total des logiciels ou des systèmes sur toute leur
durée de vie (souvent considérable !)

Des études sur les vingt dernières années ont montré que la durée de vie
moyenne du logiciel d’entreprise est de six à huit ans. Et cela augmente pour les
projets les plus ambitieux : au-delà d’un million de lignes de code, la durée de
vie dépasse la décennie, et peut aller jusqu’à 14 ans.

Maintenant, revenons à nos NetOps et souvenons-nous que les outils
d’automatisation du réseau sont, eux aussi, du code. Durant toute la durée de
vie d’un système NetOps, de nombreux administrateurs et développeurs donc seront
chargés d’ajouter un bout de code par ci, d’améliorer telle API par-là,
d’adapter tel connecteur à tel nouveau système, et bien sûr de déployer
rapidement toutes ces modifications. Mais si chacun le fait dans son coin avec les
outils de son choix, la pérennité du système NetOps, qui va pourtant devoir vivre
presque une décennie, est mise à mal.

C’est exactement pour cela que la standardisation des pratiques NetOps est une
bonne chose, et en particulier pour tous ceux qui devront développer et maintenir
des systèmes d’automatisation du déploiement et de l’orchestration réseau, ou
des infrastructures de services applicatifs.

Les silos, c’est pour les fermes

Si l’une des équipes choisit Python alors qu’une autre préfère PowerShell, on
crée un silo organisationnel qui empêchera tout partage des compétences. Et
c’est un souci ! Le premier défi de l’approche NetOps est en effet le manque de
compétences (selon 49% des NetOps ayant répondu à l’étude « State of Network
Automation 2018
 »).

Dans ces conditions, il semble totalement anormal de créer des obstacles
supplémentaires en laissant proliférer différents langages et outils à travers
l’organisation. De même qu’il serait suicidaire de choisir des langages pour
lesquels il n’y aucune source locale de talents : si les écoles d’ingénieurs
environnantes privilégient Python et que l’entreprise choisi PowerShell, le
recrutement sera probablement un peu plus compliqué…

Évidemment, il est rare qu’une organisation qui produit du code puisse
standardiser sur un seul langage. Mais généralement, elle essaie de se limiter à
une petite poignée. Et c’est exactement ce que devrait faire l’univers du
NetOps : s’inspirer de ce que font déjà les mondes du développement et du
DevOps car cela a porté ses fruits, notamment en termes d’optimisation des
talents et même, comme nous allons le voir, d’innovation.

Le temps, c’est de l’argent

Beaucoup de NetOps n’arrivent déjà pas à suivre le rythme des requêtes des
DevOps, du développement et des métiers. Et cela est accentué par le fait que les
univers du NetOps et de l’automatisation réseau sont des environnements très
hétérogènes avec peu d’intégration pré-packagée.

D’ailleurs, dans le rapport « State of Network Automation » mentionné plus
haut, le manque d’intégration disponible est le second défi majeur mentionné,
avec 47% des NetOps interrogés.

Standardiser sur les outils (et les infrastructures telles que les services
applicatifs lorsque c’est possible) offre une opportunité de réduire le poids de
l’intégration à travers l’organisation. Ce qu’une équipe développe,
l’autre peut l’utiliser pour réduire le temps d’automatisation d’un autre
projet.

Et ce n’est guère une surprise : la réutilisation fait gagner du temps, et donc
de la productivité. C’est déjà le cas avec l’Open Source, où 80 à 90 % des
applications actuelles intègrent des composants tiers ou Libres. Les mêmes
principes peuvent tout à fait être appliqués à l’automatisation réseau en
s’appuyant sur des intégrations existantes. Établir une culture du partage et de
la réutilisation à travers toute l’entreprise permettra de récolter à terme
tous les bénéfices de la standardisation.

Favoriser l’innovation

Dans ces conditions, plutôt que limiter l’innovation, comme certains ont pu le
croire, la standardisation peut au contraire se révéler être un véritable
catalyseur pour l’innovation. Car en généralisant les outils et les pratiques à
travers les domaines opérationnels, l’entreprise s’offre une plateforme
d’expertises et d’expériences partagées, avec des contributeurs capables de
mieux collaborer.

Un tel ensemble de talents coordonnés au sein de l’organisation sera plus à
même de proposer de nouvelles idées, de challenger les idées reçues ou
d’imaginer de nouvelles fonctionnalités – et tout cela sans passer par
l’habituelle (et longue !) étape de l’acclimatation.

Enfin, la standardisation accélère l’implémentation au quotidien, en grande
partie grâce à la familiarisation commune aux outils. Plus l’on travaille
longtemps avec le même outil ou le même langage, et meilleur l’on devient. Ce
qui se traduit, évidemment, par une meilleure productivité et la capacité à
proposer des solutions beaucoup plus innovantes autour de ces technologies.

La standardisation est une opportunité

Certes, à première vue une approche standardisée peut sembler rigide et
contre-productive. En particulier si le standard fait disparaitre votre outil de
prédilection. Mais quoi qu’il en soit, faire le choix de la standardisation dans
l’univers du NetOps fera toujours émerger à terme une solide fondation pour les
systèmes d’automatisation et les outils qui supportent le business. Et cela
offrira aux NetOps de nouvelles opportunités d’apporter de la valeur à
l’ensemble de la chaîne du déploiement continu.

Mais évidemment, il n’est pas question de standardiser par principe. Il est
important de prendre en considération l’existant, en matière de compétences
disponibles, notamment. Intéressez-vous notamment à la cartographie des talents
dans votre région (universités, écoles d’ingénieurs…) et des technologies
d’automatisation qui y sont enseignées, afin de vous assurer que vous ne soyez
pas isolés dans vos choix technologiques.

Et une dernière astuce : commencez à standardiser dès aujourd’hui ! Ne traitez
pas le NetOps comme l’a été en son temps la sécurité, en imaginant qu’il
s’agit de quelque chose que l’on peut venir greffer en fin de projet (demandez
d’ailleurs aux SecOps combien de temps il a fallu à la sécurité pour se
débarrasser de cette mauvaise habitude !).

Plongez dès aujourd’hui dans la standardisation, au plus tôt de vos projets
d’automatisation, afin d’éviter le piège de la dette technique et
architecturale plus tard dans le projet. Car il sera alors beaucoup plus difficile
de standardiser !

En bref, pour bien standardiser, standardisez tôt. Et vos NetOps vous remercieront…


Voir les articles précédents

    

Voir les articles suivants