La standardisation est bénéfique pour NetOps
La normalisation est parfois considérée comme une atteinte à l’innovation. Être obligé d’abandonner un buffet polyglotte et d’adopter un menu plus limité semble étouffant, c’est sûr. Cela peut être dû au fait que la normalisation est souvent associée à des normes de conformité réglementaire qui portent des noms à consonance officielle comme ISO 8076.905E et qui comportent des listes de contrôle, des auditeurs et des comités de surveillance.
La réalité est qu’il existe très peu de normes (en fait, aucune à laquelle je puisse penser) régissant le choix des langages, des protocoles et des cadres par les entreprises. Ce qui motive la standardisation dans l’entreprise, ce sont des considérations plus pratiques telles que la disponibilité des talents, la durabilité et le coût total de possession sur la durée de vie (souvent considérable) des logiciels et des systèmes.
Des études ont montré que la durée de vie moyenne des logiciels au cours des vingt dernières années est d’environ 6 à 8 ans. Il est intéressant de noter que la longévité tend à augmenter pour les programmes plus volumineux, mesurés en lignes de code (LOC). Les systèmes et logiciels avec plus d'un million de LOC semblent avoir une durée de vie supérieure à une décennie, allant de 12 à 14 ans. Même si vous pouvez considérer cela comme non pertinent, il est important de comprendre qu'en fin de compte, les systèmes d'automatisation de réseau sont des logiciels et des systèmes. Ils ont besoin des mêmes soins, de la même alimentation et de la même maintenance que les logiciels issus de votre organisation de développement. Si vous envisagez de traiter votre pipeline de production comme du code, vous devez accepter qu'un pourcentage important de ce pipeline automatisé sera du code.
Au cours de la durée de vie de ce logiciel ou de ce système, il y a donc fort à parier que plusieurs groupes d’opérateurs et de développeurs seront responsables de la mise à jour, de la maintenance, de l’exploitation et du déploiement des modifications apportées à ce logiciel ou à ce système.
Et c’est exactement ce qui est au cœur de la poussée vers la normalisation - en particulier pour NetOps alors qu’ils se lancent dans le développement et la maintenance de systèmes pour automatiser et orchestrer le déploiement et l’exploitation de l’infrastructure des services réseau et application .
Les silos sont pour les fermes
Si vous (ou votre équipe) choisissez Python tandis qu’une autre personne choisit PowerShell, vous créez en réalité un silo opérationnel qui empêche le partage des compétences. Étant donné que le principal défi auquel NetOps est confronté, comme indiqué dans l' État de l'automatisation des réseaux 2018, est le manque de compétences (comme indiqué par 49 %), il semblerait insensé de créer des frictions supplémentaires en introduisant plusieurs langages et/ou ensembles d'outils. C’est également une mauvaise idée de choisir des langages et des outils pour lesquels vous ne disposez d’aucune source locale de talents. Si d’autres organisations et universités à proximité enseignent Python et que vous choisissez d’utiliser PowerShell, vous aurez du mal à trouver des personnes possédant les compétences dont vous avez besoin pour travailler sur ce système.
Il est rare qu’une organisation se standardise sur une seule langue, mais elles ont tendance à se standardiser sur quelques-unes seulement. Les NetOps devraient s’inspirer des normes de développement et de DevOps, car cela élargira encore davantage le vivier de talents.
Le temps de valorisation est précieux
De nombreuses organisations NetOps se retrouvent déjà en retard lorsqu'il s'agit de satisfaire les exigences DevOps et commerciales pour obtenir une continuité. La triste réalité de NetOps et de l’automatisation des réseaux est qu’il s’agit d’un écosystème hétérogène avec très peu d’intégrations pré-packagées disponibles. Nous avons constaté dans l'enquête sur l'état de l'automatisation des réseaux que ce « manque d'intégration » était le deuxième défi le plus cité en matière d'automatisation, avec 47 % des NetOps d'accord.
La standardisation des ensembles d’outils et de l’infrastructure lorsque cela est possible (comme les services application ) offre la possibilité de réduire la charge de l’intégration dans l’ensemble de l’organisation. Ce qu’une équipe développe, d’autres peuvent l’exploiter pour réduire le délai de rentabilisation d’autres projets d’automatisation. La réutilisation est un facteur important pour améliorer le délai de rentabilisation. Nous constatons une réutilisation dans la propension des développeurs à l’open source et dans le fait que 80 à 90 % des applications actuelles sont composées de composants tiers/open source. Cela accélère le développement et réduit le délai de rentabilisation. Le même principe peut être appliqué à l’automatisation du réseau en tirant parti des intégrations existantes.
Établir une culture de partage et de réutilisation dans tous les domaines opérationnels pour bénéficier des avantages de la normalisation.
Stimuler l'innovation
Plutôt que d’entraver l’innovation, comme certains le croient au départ, la normalisation peut être un catalyseur d’innovation. En standardisant et en partageant les logiciels et les systèmes entre les domaines opérationnels, vous disposez d’un ensemble d’esprits et d’expériences plus solides, capables de collaborer sur de nouvelles exigences et de nouveaux systèmes. Vous créez un vivier de talents au sein de votre organisation qui peut fournir des contributions, des idées et la mise en œuvre de nouvelles fonctionnalités sans le cycle d'intégration parfois long.
La normalisation accélère également la mise en œuvre grâce à la familiarité. Plus vous travaillez avec le même langage, les mêmes bibliothèques et les mêmes outils, plus vous devenez compétent. Cela signifie une productivité accrue qui conduit à moins de temps passé à construire des roues et plus de temps à réfléchir à la manière de se différencier et d'ajouter de la valeur avec de nouvelles capacités.
La normalisation est une opportunité
La standardisation peut initialement sembler étouffante, en particulier si votre langage ou vos outils de prédilection sont supprimés de l'équipe. Mais considérer la standardisation comme une opportunité de construire une base solide pour les systèmes et logiciels d’automatisation profite à l’entreprise et offre à NetOps de nouvelles opportunités d’ajouter de la valeur à l’ensemble de la chaîne d’outils de déploiement continu.
Mais ne standardisez pas juste pour le plaisir de standardiser. Tenez compte des compétences existantes et de la disponibilité des talents locaux. Interrogez les universités et autres entreprises pour comprendre l’état actuel des compétences et des talents en matière d’automatisation et d’opérations afin de vous assurer que vous n’êtes pas la seule organisation à adopter un langage ou un ensemble d’outils donné.
Pour obtenir les meilleurs résultats à long terme, ne traitez pas la normalisation comme une question de sécurité et attendez d’avoir terminé une implémentation pour la réaliser. Adoptez la standardisation dès le début de vos efforts d’automatisation pour éviter d’être confronté à une dette opérationnelle et architecturale qui vous alourdira et rendra difficile la standardisation ultérieure.
En matière de normalisation, tout comme en matière de sécurité, mieux vaut agir tôt que tard.