Chaînes d'outils de livraison et de déploiement : Toujours soumis à l'axiome du maillon faible

De nos jours, il est difficile de se retourner sans que quelqu’un mentionne sa chaîne d’outils prenant en charge DevOps. Tout le monde en a un (oui, même nous) et tous sont rendus possibles par l'économie (autre) des API. Selon Wikipédia , une chaîne d’outils DevOps est : « un ensemble ou une combinaison d’outils qui aident à la livraison, au développement et à la gestion des applications tout au long du cycle de vie du développement logiciel, tel que coordonné par une organisation qui utilise les pratiques DevOps ».

Maintenant, cela se concentre principalement sur l’application, mais il y a aussi le côté production de la maison – où le logiciel passe généralement une bonne partie de sa vie (du moins, on l’espère). La même définition s’applique également à cela, à condition que son objectif (selon mon point de vue) soit « l’approvisionnement, la configuration et la gestion des services réseau et applicatifs tout au long du cycle de vie de l’application, coordonnés par une organisation qui utilise les pratiques DevOps ». Dans le contexte de DevOps traditionnel, cette approche élargit la phase de « publication » du cycle et couvre les « activités liées à la publication » qui incluent l’approvisionnement et le déploiement de logiciels en production. Cela inclut nécessairement (ou devrait inclure) les services réseau et applicatifs nécessaires pour permettre une diffusion sûre et sécurisée des application aux utilisateurs cibles.

Le problème est qu’aucun fournisseur ou projet open source ne contient tous les outils nécessaires pour réaliser le rêve utopique d’un déploiement continu (c’est le côté production de la maison, soit dit en passant). En fait, certains des mêmes outils utilisés du côté du développement d’applications sont également utilisés du côté de la production. De plus en plus, nous observons un croisement entre les deux mondes, ce qui est un bon signe pour le « Devops » en général, car cela montre une certaine normalisation entre deux organisations traditionnelles très ancrées avec peu de points communs, à part 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 d'application afin de répondre aux besoins d'une application en matière de sécurité, d'identité et d'évolutivité. Vous avez créé les modèles et les scripts applicables requis pour ce faire et vérifié qu'ils sont corrects, peut-être en utilisant Postman et ses capacités de script pour tester l'infrastructure virtuelle en laboratoire. Vous avez décidé que Git est un bon choix comme référentiel pour les artefacts de configuration, car le développement d'applications l'utilise déjà et peut fournir des conseils et peut-être même organiser une ou deux sessions de formation. Et vous pourriez même aller plus loin et commencer à créer une application (ou à mettre en place une implémentation OpenStack ) pour orchestrer le processus et fournir le libre-service des services individuels. Vous définissez essentiellement la chaîne d’outils de déploiement.

Et c'est là que l'axiome du maillon faible commence à montrer sa vilaine tête. Vous connaissez le principe : une chaîne n’est équivalente qu’à son maillon le plus faible. « Fort » est souligné ici car nous pouvons le remplacer par d’autres caractéristiques comme « fiable », « sécurisé » ou « évolutif » et l’axiome reste vrai. Ceci 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, où la sécurité, l’évolutivité ou la disponibilité sont compromises.

Tout comme la planification, la vérification et la surveillance sont des maillons essentiels de la chaîne d’outils DevOps, ils doivent également l’être dans la chaîne d’outils NetOps. Ceci est particulièrement important pour la surveillance, où les applications et l'infrastructure (réseau et services d'application) se croisent le plus dans les environnements de production. C'est grâce à la surveillance (visibilité) qu'une vue complète de tout, depuis les transactions commerciales jusqu'aux demandes et réponses individuelles, peut être comprise en cas de panne.

La configuration relie également nécessairement les chaînes d'outils entre elles, 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 diffusion puissent s’appuyer sur des outils similaires, il s’agit de préoccupations distinctes qui présentent souvent une grande disparité en termes de besoins. Étant donné que les services réseau et d’application peuvent être déployés sur une infrastructure partagée, les outils qui supposent une approche système unique peuvent ne pas être appropriés pour 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 est rarement applicable dans DevOps, où les applications affichent un degré élevé d’unicité.

Quoi qu’il en soit, les deux chaînes d’outils partagent un point commun : la faiblesse d’un maillon infecte toute la chaîne. Même si vous vous appuyez principalement sur des déploiements manuels qui tirent parti des scripts, il existe toujours une chaîne d’outils qui représente le processus global de livraison et de déploiement. Les gens peuvent être, et sont, des maillons dans les chaînes d’outils qui fournissent et déploient les logiciels aujourd’hui. Et il arrive que lorsqu’un lien essentiel manque – parce que Bob est sorti avec la dernière grippe – le processus s’effondre. La chaîne d’outils ne parvient pas à livrer (ou à déployer).

À mesure que vous progressez dans votre transformation numérique interne, il est important que vous reconnaissiez l’importance des chaînes d’outils DevOps et NetOps et que vous ne négligez aucun des liens qui les composent. Si nous ne prêtons pas attention à un seul de ces maillons alors que nous progressons vers l’objectif du déploiement continu, nous affaiblirons toute la chaîne. À mesure que les entreprises s’appuient de plus en plus sur ces chaînes interconnectées, un maillon faible brise non seulement un processus, mais aussi l’entreprise.