Pour gérer la complexité des cloud infrastructures natives actuelles, les entreprises ont de plus en plus besoin de technologies de supervision informatique, souvent regroupées sous le terme d’observabilité. Deux technologies sophistiquées, qui constituent des briques fondamentales de cette tendance, se développent rapidement : le Monitoring-as-Code et l’Infrastructure-as-Code.
Examinons ces technologies émergentes et voyons comment elles contribuent à superviser et à gérer des systèmes cloud native complexes.
Voir aussi : Pourquoi le cloud signifie cloud native
Infrastructure-as-Code : une fondation informatique définie par logiciel
Dans le modèle Infrastructure-as-Code, l’infrastructure physique existe toujours, mais elle prend la forme d’un modèle descriptif de ressources de calcul, de stockage et de réseau définies par logiciel, provisionnées puis fournies par les fournisseurs cloud.
Dans l’IaC, il n’y a ni câbles, ni prises, ni concentrateurs, ni routeurs ; à la place, on trouve des « topologies de connexion » définies par des fichiers de code source. Il y a donc bien sûr des câbles et des fils, mais ils résident dans le centre de données cloud et le code définit ceux que nous utilisons, à quel moment, pour quelle charge de travail et avec quel niveau d’impédance, entre autres.
Alors que nous pénétrons dans l’environnement cloud native – animé par l’Infrastructure-as-Code – avec toute la granularité Kubernetes qu’il implique pour les conteneurs, nous devons toujours garder les yeux rivés sur le défi central et nous méfier des virages imprévus et des ralentissements. Ce qui nous amène au Monitoring-as-Code.
Monitoring-as-Code : passer de 1.0 à 2.0
La « caméra embarquée toujours active » qu’est le Monitoring-as-Code (MaC) joue un rôle essentiel dans la gestion des systèmes complexes. Proche cousin de l’Observability-as-Code (OaC), sans lui être totalement synonyme, le MaC évolue rapidement : d’une fonction « simple » de collecte de données, il devient un élément des strates d’observabilité de niveau supérieur qui caractérisent les déploiements multicloud modernes.
Dans un monde où DevOps, le DevSecOps et AIOps contribuent tous à créer les rôles relativement nouveaux de l’ingénierie de fiabilité des sites (SRE), une utilisation nouvelle et plus évoluée de la supervision sera certainement nécessaire à mesure que nous passerons d’infrastructures informatiques statiques aux modèles dynamiques de l’IaC.
À son niveau le plus élémentaire, le Monitoring-as-Code (MaC) consiste à collecter des données au moyen d’agents logiciels, de plug-ins et d’éléments distincts de code source qui jouent le rôle d’« exportateurs » pour suivre les données au niveau du système et les diriger vers un référentiel. Il s’agit, si l’on veut, du MaC 1.0.
Pour atteindre le MaC 2.0 et les versions ultérieures, nous devons envisager un cycle de vie de l’observabilité plus large et le doter d’intelligence, de fonctions de diagnostic et de capacités étendues afin d’atteindre des niveaux de remédiation automatisée grâce à ce que l’on pourrait appeler une logique réactive codifiée. En termes simples, les briques fondamentales des logiciels informatiques et cloud sont en pleine mutation.
« L’une des grandes tendances technologiques de 2022 sera l’intégration de l’“observabilité et des pipelines” en tant que marchés adjacents », a déclaré James Governor, cofondateur du cabinet d’analystes technologiques RedMonk. « Les tests se déplacent vers la gauche, mais aussi vers la droite, en production. Les pipelines de livraison logicielle sont désormais des applications stratégiques. Nous voyons les acteurs de l’observabilité travailler plus étroitement avec les entreprises qui fournissent des outils de CI/CD et de livraison logicielle, afin de faciliter la vie de leurs clients. »
Selon Governor, les deux disciplines (ou marchés) que sont l’observabilité et la livraison logicielle sont si proches qu’elles convergent pour permettre ce que nous pouvons appeler la « livraison progressive ».
Voir aussi : Les tendances de l’AIOps
Cas d’usage des technologies d’observabilité « as code »
« En passant à la livraison progressive, nous pouvons commencer à nous concentrer sur des cas d’usage tels que les déploiements blue/green, les déploiements canary, les feature flags et les lancements invisibles, avec des déploiements progressifs auprès de cohortes d’utilisateurs spécifiques afin de limiter le rayon d’impact. La production devient alors partie intégrante du cycle de vie de la livraison logicielle », a expliqué Governor.
Il affirme que la révolution de l’« as code » fait progresser tout cela, en permettant des pipelines et des extensions plus sophistiqués, tandis que les entreprises cherchent à moderniser la livraison de leurs applications, avec de meilleurs tests, davantage d’automatisation et une observabilité intégrée.
Parmi les acteurs actuels du Monitoring-as-Code figure Sumo Logic avec son projet open source Sensu. Présenté comme un « pipeline d’observabilité » conçu pour fournir du Monitoring-as-Code sur n’importe quel cloud, Sensu promet de consolider les outils de supervision et de combler les lacunes d’observabilité entre les silos de données grâce au diagnostic automatisé et à l’autoréparation. En résumé, il couvre tout le spectre de l’informatique moderne, du bare metal à Kubernetes.
Sumo Logic a racheté le projet Sensu en juin 2021, et le CEO Caleb Hailey ainsi que le cofondateur Sean Porter ont rejoint la nouvelle société mère dans des fonctions destinées à poursuivre leurs travaux. Ils avaient conçu Sensu alors qu’ils travaillaient sur un projet interne visant à remplacer une installation obsolète de supervision d’infrastructure Nagios pour une entreprise d’archivage d’informations dans le cloud.
Sans nécessairement dénigrer leur valeur, Porter lui-même a décrit les outils de MaC 1.0 pour ce qu’ils étaient : des agents logiciels conçus pour transmettre les informations des fichiers système à des outils de gestion de configuration comme Puppet, Chef, Helm, Terraform, Ansible ou autres. Il a décrit cette approche comme similaire à l’adaptation a posteriori d’outils de supervision traditionnels au paradigme DevOps moderne.
Tout cela nous ramène à un autre paradigme moderne de mise en œuvre des plateformes applicatives. Le monde de la CI/CD peut intégrer profondément le MaC dans sa structure, à condition d’adopter le MaC 2.0 évolué en son cœur.
Le MaC 1.0 dans la CI/CD consiste à utiliser des outils de supervision pour tester l’état opérationnel et le bon fonctionnement des applications et des services associés. Le MaC 2.0 dans la CI/CD consiste à utiliser des outils de supervision dotés d’une logique réactive codifiée pour créer et tester des applications. Et à automatiser leur bon fonctionnement opérationnel dans des environnements de production actifs.
À mesure que l’utilisation du MaC 2.0 se développe dans les environnements contemporains de CI/CD qui recourent largement à la conteneurisation via des technologies comme Kubernetes, ainsi qu’à l’intelligence artificielle, le « conditionnement commun » des conteneurs peut nous permettre d’étendre la CI/CD à un pipeline encore plus formalisé.
Sumo Logic’s Porter qualifie ces évolutions de passage à la nouvelle nouvelle Infrastructure-as-Code, un terme qui doit clairement être réinventé (« néo-IaC », peut-être). Cela s’applique également, de toute évidence, à la manière dont nous créons des pipelines de CI/CD intégrant davantage de fonctions opérationnelles, notamment la supervision et l’observabilité.
Superviser plus étroitement le pipeline de CI/CD
Il est important de créer un pipeline d’intégration continue/livraison continue (CI/CD) plus intelligent sur le plan opérationnel, réactif et fonctionnel, qui ne se contente pas de « faire et voir ». Il « voit, comprend et réagit » également, afin que ce nouveau socle IaC puisse contribuer à bâtir un système capable de fournir les services cloud très exigeants dont ont besoin les entreprises cloud native dites à haute vélocité.
« Le Monitoring-as-Code (MaC) résout un problème récurrent de nombreux projets : des problèmes inattendus survenant pendant les tests de préproduction ou les déploiements passent inaperçus. Nous perdons des heures à laisser se poursuivre des tests défaillants, puis davantage de temps à diagnostiquer le problème et, bien sûr, nous manquons l’occasion d’en rechercher la cause racine au moment de la défaillance », a expliqué Seng Phung-Lu, AVP de l’ingénierie de fiabilité des sites chez TD Bank.
Phung-Lu explique qu’en déployant les outils de MaC aux côtés d’une application via un pipeline unifié unique, son équipe et lui peuvent détecter rapidement les problèmes et éviter, selon ses propres termes, de devoir « garder manuellement un œil » sur les tests et le processus de CI/CD.
L’objectif ultime : une supervision continue et complète de bout en bout
La véritable valeur de ces technologies émergentes réside peut-être dans une nouvelle définition de ce que nous entendons par supervision de bout en bout.
À l’époque, la supervision de bout en bout désignait l’observabilité appliquée à tout, du système d’exploitation (OS) et de l’interface utilisateur (UI) de l’appareil aux fonctions de calcul, de stockage et d’analyse, puis de nouveau à l’utilisateur. La nouvelle supervision de bout en bout englobe tout cela, avec en plus la capacité d’assurer la supervision sur toute l’étendue de l’infrastructure sur laquelle reposent tous ces éléments.
Dans le cercle vertueux du MaC 2.0 au sein d’un environnement néo-IaC de bout en bout, une nouvelle relation symbiotique commence à se développer : les métriques applicatives sont collectées et détectées automatiquement en réponse aux modifications du code et aux nouveaux déploiements. L’extension continue de la pile informatique bénéficie des « erreurs apprises » (échecs d’exécution du code) déjà rencontrées, et la pile elle-même puise dans son propre ADN évolutif.
À propos de l’auteur :
Adrian Bridgwater est un journaliste de premier plan spécialisé dans les technologies émergentes.