Peu importe la rapidité avec laquelle vous pouvez livrer si le déploiement retarde la mise en production. Bien que les équipes NetOps s’ouvrent progressivement à l’automatisation et à l’orchestration, leurs efforts pour accélérer le déploiement se heurtent à des difficultés majeures. Les équipes DevOps sont les mieux placées pour les aider à y parvenir.
LA TRANSFORMATION NUMÉRIQUE PASSE PAR LE DEVOPS

Il existe indéniablement un lien entre la transformation numérique et le DevOps. Sous l’effet de la transformation numérique, 48 % des organisations s’orientent vers des mises en production plus fréquentes de leurs applications. 62 % automatisent et orchestrent leurs systèmes et processus informatiques. 52 % modifient leur façon de développer des applications (notamment en adoptant les méthodes agiles). Enfin, 42 % explorent les conteneurs et les microservices. Des composants fondamentaux des applications jusqu’aux méthodes employées pour les commercialiser, la transformation numérique permet au DevOps de passer de la « livraison continue » au « déploiement continu ». Rappelons que la « livraison » ne désigne pas la mise sur le marché, mais la mise en production, étape à laquelle le processus de déploiement démarre et rend l’application utilisable.
En effet, « acceptable pour une utilisation » ne signifie pas simplement que « l’application fonctionne correctement ». Cette notion englobe un ensemble d’exigences qui doivent être mises en œuvre et déployées sous la forme de services applicatifs. Évolutivité, sécurité, performances, supervision : tous ces éléments doivent être en place avant que l’application puisse être considérée comme « acceptable pour une utilisation ». C’est ce qui constitue aujourd’hui le « pipeline de déploiement ».
LE DÉPLOIEMENT A BESOIN DU DEVOPS POUR CONCRÉTISER LES PROMESSES DE L’AUTOMATISATION ET DE L’ORCHESTRATION
Malheureusement, une excursion à ski avec George Jetson et Fred Pierrafeu illustre de manière bien trop fidèle l’état de l’automatisation de la livraison et du déploiement. Le premier, venu du futur, utilise des skis à réaction, tandis que Fred, qui vit encore dans le passé, se débrouille avec des skis à propulsion manuelle. Si vous avez deviné que George Jetson sur ses skis à réaction représente le DevOps pratiquant la livraison continue, vous avez raison. Et si vous avez deviné que le NetOps tente de pratiquer le déploiement continu à l’aide d’une méthode essentiellement manuelle, vous avez également raison.
Les équipes NetOps sont chargées de provisionner, de déployer et d’exploiter les 14 services applicatifs qu’utilisent en moyenne les organisations aujourd’hui. Cela englobe aussi bien l’évolutivité (équilibrage de charge et contrôle des flux entrants) que la sécurité (pare-feu d’applications web et protection contre les bots), sans oublier des services plus méconnus 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 avancer plus vite, il leur manque encore les skis propulsés par fusée de leurs homologues DevOps.
Les disparités dans l’automatisation des pipelines peuvent entraîner des retards frustrants

L’écart entre les taux d’automatisation des différents composants des services applicatifs nécessaires à la « livraison continue » montre qu’il faut éliminer les « forces déséquilibrées » qui conduisent encore la majorité des organisations à recourir à des méthodes manuelles. Cela vaut tout particulièrement pour les organisations qui n’ont automatisé AUCUN composant de déploiement. C’est toute la différence entre des skis équipés de fusées et des skis traditionnels. Même celles qui sont parvenues à automatiser certaines parties du pipeline ne l’ont pas fait de manière uniforme : seules 21 % des organisations ont automatisé les quatre composants clés. 11 % n’ont réussi à automatiser qu’un seul domaine, et 25 % en ont automatisé deux.
Imaginez-vous en plein vol lorsque, soudain, les fusées de vos skis disparaissent.
Nous ne pouvons plus compter sur la solution traditionnelle consistant à « mobiliser davantage de personnes » pour accélérer le déploiement. Cela ne fait qu’aggraver les retards en ajoutant des niveaux de communication et des obstacles dans les processus entre la mise en production et la livraison au consommateur.

Ces retards mécontentent les équipes métier, car elles doivent attendre et, pire encore, conduisent souvent à sauter certaines étapes (comme la sécurité) pour rattraper le temps perdu. Pour y remédier, nous devons identifier et corriger les « forces déséquilibrées » qui ralentissent le déploiement continu.
QUE SONT CES « FORCES DÉSÉQUILIBRÉES » ET COMMENT LE DEVOPS PEUT-IL LES RÉÉQUILIBRER ?

Les facteurs qui déséquilibrent le déploiement se retrouvent dans les difficultés évoquées par les équipes NetOps. Les compétences, les politiques, les budgets et l’intégration constituent des obstacles majeurs à la mise en œuvre du déploiement continu. Les équipes NetOps savent écrire des scripts, ne vous méprenez pas, et elles le font constamment. Mais l’écriture de scripts n’est pas de l’automatisation et ne répond pas à la nécessité d’intégrer jusqu’à 14 appareils, systèmes et services différents. Les équipes NetOps ont besoin d’aide pour identifier et mettre en pratique les outils et les méthodologies qui permettent non seulement d’intégrer ces systèmes disparates, mais aussi de piloter le processus de déploiement de manière cohérente, prévisible et reproductible.
C’est là que le DevOps peut aider les équipes NetOps à mettre en place une pratique efficace du déploiement continu.
LA COLLABORATION DOIT DÉPASSER LA FRONTIÈRE ENTRE L’IT ET LE DÉVELOPPEMENT

La culture n’est pas facultative. Elle a un impact très concret sur les comportements et les pratiques. À elle seule, la structure des équipes modifie radicalement l’automatisation des pipelines, les équipes traditionnelles monofonctionnelles étant à la traîne par rapport à leurs homologues modernes axées sur le DevOps. Favorisez des structures d’équipe plus collaboratives. Dans le même esprit, une équipe collaborative doit s’accorder sur des indicateurs clés. Des indicateurs communs permettent aux équipes NetOps et Sécurité d’œuvrer en faveur du déploiement continu sans être pénalisées. À l’heure actuelle, près des trois quarts des équipes NetOps sont évaluées sur la DISPONIBILITÉ DU RÉSEAU. La fréquence des déploiements entre à peine en ligne de compte pour elles. Elles vont donc s’attacher à maintenir le réseau opérationnel, car c’est sur cet objectif qu’elles doivent se concentrer. Des indicateurs communs permettent aux équipes NetOps de se consacrer aux besoins de l’entreprise : des déploiements plus rapides et plus fréquents.
Enfin, l’empathie est indispensable. Vous faites tous partie de la même équipe et, aussi surprenant que cela puisse paraître, vous accordez de l’importance aux mêmes choses. Les équipes NetOps sont tout aussi susceptibles que les équipes DevOps d’accorder une grande importance à l’automatisation des pipelines. N’oubliez pas que les équipes DevOps ont dix ans d’avance sur les équipes NetOps lorsqu’il s’agit d’identifier et de surmonter les obstacles liés à l’intégration, aux outils et aux compétences. Les équipes collaboratives peuvent apporter leur aide en favorisant la standardisation d’outils couvrant l’ensemble du processus, de la livraison au déploiement (comme Jenkins et GitHub/GitLab).
Organisez des déjeuners de partage des connaissances. Proposez d’accompagner un homologue NetOps et partagez avec lui des conseils ainsi que des liens vers des tutoriels et des communautés qui permettront aux équipes NetOps d’apprendre les ficelles du métier. Créez un « Centre d’excellence en automatisation » ou une communauté afin de contribuer à l’établissement de bonnes pratiques, de partager des solutions et d’encourager la transmission des connaissances permettant de remédier à ces « forces déstabilisatrices ».
Le DevOps ne doit pas — et ne peut pas — s’arrêter à la livraison. Une application n’est réellement « terminée » que lorsqu’elle est entre les mains des utilisateurs auxquels elle est destinée. Cela signifie que le déploiement — et son pipeline, certes complexe, d’équipements et de services applicatifs — doit être automatisé afin de réduire le temps nécessaire pour y parvenir. Les équipes DevOps disposent des compétences, des outils et de l’expérience nécessaires pour aider les équipes NetOps à chausser des skis propulsés par des fusées, afin qu’elles puissent, elles aussi, avancer aussi vite que l’exigent les besoins de l’entreprise.
À 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.