Peu importe la rapidité avec laquelle vous pouvez livrer si le déploiement retarde la publication. Alors que les NetOps s'habituent à l'automatisation et à l'orchestration, leurs efforts pour accélérer le déploiement sont confrontés à des défis importants. DevOps est le mieux placé pour les aider à y parvenir.
Il existe indéniablement un lien entre la transformation numérique et DevOps. Grâce à DX, 48 % des organisations s'orientent vers une livraison plus fréquente des applications en production. 62 % automatisent et organisent les systèmes et processus informatiques. 52 % changent leur façon de développer des applications (pensez à Agile). Et 42 % explorent les conteneurs et les microservices. Depuis les éléments de base des applications jusqu'aux méthodes mises en place pour les commercialiser, la transformation numérique signifie que DevOps a un moyen d'étendre la « livraison continue » au « déploiement continu ». N'oubliez pas que « livraison » ne signifie pas au marché, mais à la production, là où le processus de déploiement démarre et amène l'application dans un état acceptable pour la consommation.
C’est parce que « acceptable pour la consommation » ne signifie pas simplement « l’application fonctionne correctement ». Il englobe un ensemble d’exigences qui doivent être mises en œuvre et déployées sous forme de services d’application. Échelle, sécurité, performances, surveillance : tous ces éléments doivent être en place avant que l'application puisse être considérée comme « acceptable pour la consommation ». C’est ce qui constitue le « pipeline de déploiement » aujourd’hui.
Malheureusement, une représentation beaucoup trop précise de l’état de l’automatisation dans la livraison et le déploiement est un voyage de ski avec George Jetson et Fred Flintstone. Le premier, venant du futur, se déplace en jet-ski tandis que Fred, vivant toujours dans le passé, se débrouille avec des skis à propulsion manuelle. Si vous avez deviné que George Jetson sur ses skis propulsés par fusée est DevOps et fait de la livraison continue, vous avez raison. Et si vous avez deviné que NetOps essaie de réaliser un déploiement continu avec une méthode principalement manuelle, vous auriez également raison.
Les NetOps sont les personnes chargées de provisionner, de déployer et d'exploiter les 14 services d'application en moyenne utilisés par les organisations aujourd'hui. Cela comprend tout, de l'évolutivité (équilibrage de charge et contrôle d'entrée) à la sécurité (pare-feu d'applications Web et défenses contre les robots) jusqu'aux services plus obscurs qui améliorent les performances de l'ensemble de la pile prenant en charge une application.
Aujourd'hui, même s'ils disposent de skis pour les aider à se déplacer plus rapidement, ils ne disposent toujours pas des skis assistés par fusée de leurs homologues DevOps.
La disparité entre les taux d’automatisation des différents composants des services d’application nécessaires pour parvenir à un « déploiement continu » indique la nécessité d’éliminer les « forces déséquilibrées » qui font que les méthodes manuelles sont encore utilisées par la majorité des organisations. Cela est particulièrement vrai pour les organisations qui n’ont automatisé aucun composant de déploiement. C'est la différence entre les skis à propulsion fusée et les skis traditionnels. Même celles qui ont réussi à automatiser des éléments du pipeline ne l’ont pas fait de manière cohérente : seulement 21 % des organisations ont automatisé les quatre composants clés. 11 % n’ont réussi à automatiser qu’un seul domaine, 25 % en ont réussi deux.
Imaginez que vous êtes en plein vol et que soudainement les fusées de vos skis disparaissent.
Nous ne pouvons plus compter sur la solution traditionnelle consistant à « envoyer plus de personnes sur le problème » pour accélérer le déploiement. Cela ne fait qu’aggraver les retards en ajoutant des couches de communication supplémentaires et des nids-de-poule dans les processus entre la livraison à la production et la livraison au consommateur.
Ces retards rendent les entreprises mécontentes car elles doivent attendre et, pire encore, les obligent souvent à sauter des étapes (comme la sécurité) pour rattraper le temps perdu. Pour résoudre ce problème, nous devons identifier et traiter les « forces déséquilibrées » qui ralentissent le déploiement continu.
Les forces déséquilibrantes dans le déploiement peuvent être trouvées dans les défis cités par NetOps. Les compétences, les politiques, les budgets et l’intégration constituent des obstacles importants à la réalisation d’un déploiement continu. Les NetOps peuvent écrire des scripts, ne vous méprenez pas, et ils le font tout le temps. Mais les scripts ne sont pas une automatisation et ne répondent pas au besoin d’intégration sur 14 appareils, systèmes et services potentiellement différents. NetOps a besoin d’aide pour identifier et mettre en pratique les outils et méthodologies qui non seulement permettent l’intégration entre ces systèmes disparates, mais pilotent également le processus de déploiement de manière cohérente, prévisible et reproductible.
C’est là que DevOps peut aider NetOps à créer une pratique de déploiement continu réussie.
La culture n’est pas facultative. Cela a un impact très réel sur les comportements et les pratiques. La structure de l’équipe à elle seule modifie radicalement l’automatisation du pipeline, les équipes traditionnelles à fonction unique prenant du retard sur leurs homologues contemporaines axées sur DevOps. Encourager des structures d’équipe plus collaboratives. Dans la même veine, une équipe collaborative doit être alignée sur des indicateurs clés. Les métriques partagées permettent à NetOps et à la sécurité de travailler vers un déploiement continu sans pénalité. À l’heure actuelle, près des trois quarts des NetOps sont mesurés en fonction du TEMPS DE DISPONIBILITÉ DU RÉSEAU. La fréquence de déploiement est à peine perceptible pour eux. Ils vont se concentrer sur le maintien du réseau, car c'est sur cela qu'ils doivent se concentrer. Les métriques partagées donnent à NetOps la permission de se concentrer sur les besoins de l'entreprise : des déploiements plus rapides et plus fréquents.
Enfin, l’empathie est nécessaire. Vous faites tous partie de la même équipe et, vous serez peut-être surpris de l’apprendre, vous accordez de l’importance aux mêmes choses. Les NetOps sont tout aussi susceptibles d’accorder une grande importance à l’automatisation des pipelines que les DevOps. N’oubliez pas que DevOps a dix ans d’avance sur NetOps pour surmonter les obstacles liés à l’intégration, aux outils et aux compétences. Les équipes collaboratives peuvent aider en promouvant la standardisation des outils qui s’étendent de la livraison au déploiement (comme Jenkins et GitHub/GitLab).
Organisez des déjeuners et des ateliers d'apprentissage. Proposez d'encadrer un homologue NetOps et de partager des idées et des liens vers des tutoriels et des communautés qui peuvent offrir aux NetOps l'opportunité d'apprendre les ficelles du métier. Créez un « Centre d'excellence en automatisation » ou une communauté pour aider à établir les meilleures pratiques, partager des solutions et encourager le partage des connaissances qui s'attaquent à ces « forces déséquilibrantes ».
DevOps ne doit pas – et ne peut pas – s’arrêter à la livraison. Une application n’est pas vraiment « terminée » tant qu’elle n’est pas entre les mains de ses destinataires. Cela signifie que le déploiement, ainsi que son pipeline complexe d’appareils et de services d’application, doivent être automatisés pour réduire le temps nécessaire pour y parvenir. DevOps possède les compétences, les outils et l’expérience nécessaires pour aider NetOps à équiper ses skis de fusées afin qu’ils puissent, eux aussi, évoluer aussi vite que l’entreprise en a besoin.