Chaînes d’outils de livraison et de déploiement : toujours soumises à l’axiome du maillon le plus faible

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

De nos jours, il est presque impossible de faire un pas sans entendre quelqu’un parler de sa chaîne d’outils DevOps. Tout le monde en a une (oui, même nous), et toutes sont rendues possibles par l’(autre) économie des API. Selon Wikipédia, une chaîne d’outils DevOps est « un ensemble ou une combinaison d’outils qui facilitent la livraison, le développement et la gestion des applications tout au long du cycle de vie du développement logiciel, sous la coordination d’une organisation qui applique des pratiques DevOps ».

maillon faible

Cela se concentre principalement sur l’application, mais il y a aussi le volet production, où les logiciels passent généralement une bonne partie de leur existence (du moins, on l’espère). La même définition s’y applique également, à ceci près que l’accent est mis (de mon point de vue) sur « l’approvisionnement, la configuration et la gestion des services réseau et applicatifs tout au long du cycle de vie de l’application, sous la coordination d’une organisation qui applique les pratiques DevOps ». Dans le contexte du DevOps traditionnel, cette approche élargit la phase de « mise en production » du cycle et couvre les « activités liées à la mise en production », notamment l’approvisionnement et le déploiement des logiciels en production. Cela inclut nécessairement (ou devrait inclure) les services réseau et applicatifs requis pour assurer une mise à disposition sûre et sécurisée des applications auprès des utilisateurs cibles.

Le fait est qu’aucun fournisseur ni projet open source ne réunit à lui seul tous les outils nécessaires pour concrétiser le rêve utopique du déploiement continu (qui relève, soit dit en passant, de la mise en production). En réalité, certains des outils utilisés côté développement des applications le sont également côté production. Nous observons de plus en plus de passerelles entre ces deux univers, ce qui est bon signe pour le « DevOps » en général : cela témoigne d’un certain rapprochement entre deux entités traditionnellement très cloisonnées, qui n’ont guère en commun que l’application.

Vous pouvez donc utiliser Puppet ou Chef en combinaison avec VMware et Cisco pour automatiser une pile complète de services réseau et applicatifs afin de répondre aux besoins d’une application en matière de sécurité, d’identité et de mise à l’échelle. Vous avez créé les modèles et scripts nécessaires, puis vérifié leur bon fonctionnement, peut-être en utilisant Postman et ses fonctionnalités de script pour effectuer des tests sur une infrastructure virtuelle en laboratoire. Vous avez décidé que git constitue un bon choix comme dépôt d’artefacts de configuration, car l’équipe de développement d’applications l’utilise déjà et peut fournir des conseils, voire organiser une ou deux sessions de formation. Vous pouvez même aller plus loin et commencer à développer une application (ou à déployer une implémentation OpenStack) afin d’orchestrer le processus et de permettre l’utilisation en libre-service de chaque service. En substance, vous définissez la chaîne d’outils de déploiement.

Et c’est là que l’axiome du maillon faible commence à montrer son côté pernicieux. Vous connaissez le principe : une chaîne n’est jamais plus solide que son maillon le plus faible. Le terme « solide » est mis en avant ici, car on peut le remplacer par d’autres caractéristiques, comme « fiable », « sécurisée » ou « évolutive », sans que l’axiome perde de sa pertinence. C’est important, car lorsque vous commencez à définir la chaîne d’outils qui prendra en charge le déploiement continu, chaque « maillon » de cette chaîne peut devenir un point de défaillance susceptible de compromettre la sécurité, l’évolutivité ou la disponibilité.

Tout comme la planification, la vérification et la supervision constituent des maillons essentiels de la chaîne d’outils DevOps, elles doivent également l’être dans la chaîne d’outils NetOps. Cela est particulièrement important pour la supervision, car c’est dans les environnements de production que les applications et l’infrastructure (services réseau et applicatifs) interagissent le plus. En cas de défaillance, la supervision (visibilité) permet d’obtenir une vue d’ensemble complète, allant des transactions métier aux requêtes et réponses individuelles.

La configuration relie également nécessairement les chaînes d’outils, car la configuration des services réseau et applicatifs peut être — et est souvent — propre à une application donnée.

Bien que les mécanismes de packaging et de mise en production puissent s’appuyer sur des outils similaires, il s’agit de problématiques distinctes dont les besoins diffèrent souvent considérablement. Les services réseau et applicatifs pouvant être déployés sur une infrastructure partagée, les outils reposant sur une approche monolithique peuvent ne pas convenir aux NetOps. À l’inverse, l’utilisation de modèles est de plus en plus courante pour déployer rapidement des services standardisés en production, mais ceux-ci sont rarement adaptés au DevOps, où les applications présentent un degré élevé de spécificité.

Quoi qu’il en soit, les deux chaînes d’outils ont un point commun : la faiblesse d’un seul maillon compromet l’ensemble de la chaîne. Même si vous vous appuyez sur des déploiements essentiellement manuels faisant appel à des scripts, il existe toujours une chaîne d’outils qui représente le processus global de livraison et de déploiement. Les personnes peuvent constituer, et constituent effectivement, des maillons des chaînes d’outils qui assurent aujourd’hui la livraison et le déploiement des logiciels. Ainsi, lorsqu’un maillon essentiel vient à manquer — parce que Bob est absent en raison de la dernière grippe en date —, le processus s’interrompt. La chaîne d’outils ne parvient plus à assurer la livraison (ou le déploiement).

À mesure que vous poursuivez votre transformation numérique interne, il est important de prendre conscience du rôle essentiel des chaînes d’outils DevOps et NetOps et de ne négliger aucun des maillons qui les composent. Alors que nous progressons vers l’objectif du déploiement continu, le simple fait de ne pas accorder suffisamment d’attention à l’un de ces maillons affaiblira toute la chaîne. À mesure que l’entreprise dépend de plus en plus de ces chaînes interconnectées, un maillon faible ne compromet pas seulement un processus : il met également l’entreprise en péril.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

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 Vittie