La plupart des discussions sur l’ingénierie de plateforme et les plateformes de développement internes (IDP) commencent par un objectif bien connu : réduire la charge cognitive des développeurs de logiciels.

C’est un objectif valable et c’est généralement là où débutent les conversations sur les IDP. Cependant, lorsque nous avons commencé à travailler sur des plateformes de calibre entreprise, nous avons constaté qu’un autre problème a émergé très rapidement.

Les plus grands obstacles ne se situent pas uniquement du côté des développeurs d’application, mais aussi des équipes à qui on demandait de bâtir, maintenir et automatiser l’infrastructure et les plateformes sur lesquelles tous les autres comptaient.

Notre mandat initial était de créer une solution d’ingénierie de plateforme qui inclut les meilleures pratiques, une IDP personnalisable et extensible et les compétences requises pour gérer tout cela au même endroit. Nous avons réussi à créer tout ça avec un accent important sur la productivité des développeurs. En même temps, à mesure que nous abordions plus en détail les défis opérationnels quotidiens, nous avons effectué un changement délibéré. Nous avons commencé à traiter les ingénieurs en automatisation, les SRE et les opérateurs d’infrastructure comme des utilisateurs de premier plan de la plateforme. Ce changement de perspective nous a permis de concevoir quelque chose de plus utile : non seulement un catalogue, mais aussi un environnement de travail où les équipes plate-forme pouvaient créer, tester, gouverner et exploiter l’automatisation de façon plus cohérente. Nous avons véritablement réutilisé l’ensemble de la solution d’ingénierie de plateforme pour les ingénieurs de plateforme, les ingénieurs d’opérations infrastructurelles, les SRE, les ingénieurs de fiabilité réseau, etc. Désormais, les mêmes concepts de l’ingénierie de plateforme conçus pour les développeurs de logiciels s’appliquent aux automatisations et aux développeurs liés à GenAI, mais spécifiquement pour la préparation, la mise à niveau et les opérations d’automatisation de plateforme et d’infrastructure.

Le goulot d’étranglement caché dans les opérations applicatives

Dans de nombreux grands environnements, les opérations applicatives ralentissent parce que l’automatisation des opérations applicatives et des plateformes middleware est dispersée. Nous avons vu des scripts placés dans divers dépôts, de l’infrastructure comme code exécutée à partir de machines individuelles, et les connaissances sur les versions d’application et de plateforme détenues par quelques ingénieurs expérimentés. Rien de cela n’était dû à une mauvaise intention. C’était simplement le résultat d’équipes résolvant des problèmes urgents au fil du temps sans modèle d’opération commun. L’impact devenait évident chaque fois qu’une équipe d’application avait besoin d’un nouvel environnement, d’une mise à jour de pipeline de livraison ou d’une modification de configuration. La demande devenait généralement un billet et l’attente commençait.

Ce qui est devenu clair pour nous, c’est que le retard tenait rarement à la capacité. Les équipes d’opérations applicatives savaient ce qu’elles faisaient. Le vrai problème, c’est que chaque changement nécessitait trop d’effort manuel, trop de changements de contexte, et trop de validation minutieuse. Si nous voulions améliorer les cycles de livraison d’applications, nous devions d’abord améliorer le flux de travail quotidien des ingénieurs qui bâtissaient et soutenaient ces pipelines de livraison. La solution HCL IDP est ainsi devenue l’endroit où nous avons harmonisé ce flux de travail.

L’introduction de l’ingénierie de plateforme et de l’IDP pour les plateformes s’est avérée une bouée de sauvetage pour les opérations applicatives. Maintenant, les cycles critiques de livraison applicative sont gérés à l’aide d’automatisations « one-click ». Et tous les scripts d’automatisation sont conservés dans GitHub avec des artéfacts principaux disponibles via l’IDP, ce qui a accru la réutilisabilité et réduit de façon significative les délais de traitement.

Personnaliser Backstage pour AppOps et la gestion de plateforme

Notre solution IDP est basée sur Backstage et Backstage est performant pour cataloguer les services et composants logiciels, mais nous avions besoin qu’elle représente les ressources réellement utilisées au quotidien par nos équipes AppOps et plateformes.

Nous avons élargi le catalogue pour inclure des modules Terraform, des gabarits de pipelines CI/CD, des scripts opérationnels, des graphiques Helm, des modèles de configuration et des définitions de politique comme code. Cela a offert aux ingénieurs un point unique où retrouver les ressources d’automatisation approuvées au lieu de fouiller dans plusieurs dépôts ou de demander la dernière version autour d’eux.

Ce petit changement a transformé l’utilité de la plateforme. Les ingénieurs en automatisation pouvaient voir ce qui existait déjà, comprendre les dépendances, examiner l’historique des exécutions et réutiliser des modèles en toute confiance. Avec le temps, cela a aussi réduit le nombre de solutions ponctuelles créées pour des besoins d’environnement et de livraison similaires.

HCL IDP–Génération de code alimentée par l’IA intégrée

La solution HCL IDP, intégrée à la trame CARE, a été considérablement modifiée et de nombreuses fonctions supplémentaires ont été ajoutées dans les dernières années. Toutes ces fonctionnalités sont basées sur les commentaires des clients et sur les avancées technologiques majeures en cours.

L’un des ajouts les plus pratiques que nous avons faits a été un assistant alimenté par l’IA à l’intérieur de l’IDP. Nous ne l’avons pas présenté comme un remplacement du jugement de l’ingénieur. Nous l’avons plutôt utilisé pour éliminer certains efforts répétitifs liés à la rédaction de code d’automatisation et de configuration de plateforme. Les SRE AppOps examinaient, ajustaient et validaient toujours la sortie, mais le point de départ était bien plus rapide.

L’assistant a été adapté à nos modèles d’architecture internes, à nos attentes en matière de sécurité et à notre outillage préféré. Par exemple, lorsqu’un ingénieur avait besoin d’un manifeste Kubernetes, d’un playbook Ansible ou d’un diagramme Helm pour un scénario de livraison spécifique, l’assistant pouvait générer un brouillon conforme, aligné sur nos normes. Le véritable avantage n’était pas que l’IA écrivait du code, mais que les ingénieurs passaient moins de temps à produire du code répétitif et plus de temps à réfléchir au risque, aux dépendances et à l’incidence opérationnelle.

Plans directeurs pour le déploiement rapide de la plateforme

Nous avons aussi appris que la génération de code d’automatisation n’est que la moitié du problème. La question la plus importante est de savoir où le tester de façon sécuritaire. Auparavant, les ingénieurs avaient souvent un accès limité à des environnements d’essai réalistes et la validation d’un changement d’infrastructure pouvait exiger la coordination entre plusieurs équipes. Cela engendrait de l’hésitation, en particulier pour les changements touchant le réseau, les migrations de bases de données, les politiques de clusters ou les services de plateforme partagés.

Pour remédier à cela, nous avons introduit des plans de déploiement de plateforme dans l’IDP. Ce n’étaient pas des modèles génériques d’applications. Ils étaient conçus pour la validation au niveau plateforme et notre solution phare ePACE a servi d’outil habilitant. Un ingénieur pouvait créer un environnement Kubernetes éphémère avec l’ensemble de la plateforme standard, appliquer un nouveau script ou une configuration, observer le comportement puis démanteler l’environnement une fois le test terminé. Tout cela à l’aide d’ePACE en arrière-plan de l’IDP, de façon transparente.

Cela a offert aux équipes une façon plus sécuritaire d’expérimenter. Cela n’a pas éliminé le besoin de révision ou de contrôle de changements, mais a atténué la crainte de tester les changements d’infrastructure. Les ingénieurs pouvaient valider le comportement dans un environnement beaucoup plus près de la production, sans risquer les charges actives. Le nettoyage automatique a aussi aidé à éviter le problème bien connu des environnements de test qui restent actifs indéfiniment.

Observabilité en temps réel pour la clarté opérationnelle

Un autre enjeu que nous voulions régler était la visibilité opérationnelle. En pratique, les ingénieurs devaient souvent passer de l’IDP aux outils de journalisation, aux tableaux de bord de surveillance et aux systèmes de pipeline pour comprendre si un changement avait eu l’effet désiré. Ce changement de contexte ralentissait le dépannage et compliquait le lien entre l’action de déploiement et ses conséquences opérationnelles.

Nous avons introduit des vues d’observabilité clés dans HCL IDP, permettant ainsi aux équipes de voir l’utilisation des ressources, la latence, les taux d’erreur et la santé de l’environnement au même endroit que celui où elles initiaient ou examinaient les changements de plateforme. Cela a rendu les révisions plus concrètes. Si un nouveau script d’automatisation augmentait la consommation de ressources ou introduisait des erreurs, l’équipe pouvait voir rapidement le signal et réagir avec un meilleur contexte.

Pousser le GreenOps avec des tableaux de bord de durabilité

À mesure que la plateforme a mûri, nous avons aussi élargi nos préoccupations au-delà de la rapidité et de la fiabilité. Les coûts et la durabilité faisaient désormais partie de la même discussion. Nous avons intégré Kepler, l’exportateur efficace du niveau de consommation d’énergie basé sur Kubernetes, afin de donner aux équipes de la visibilité sur les patrons de consommation énergétique au niveau des charges applicatives. Ceci s’est révélé utile, car cela reliait l’efficacité de l’infrastructure aux choix de conception applicative.

Pour les développeurs, cela rendait l’efficacité plus concrète. Au lieu de ne voir que les nombres de CPU et de mémoire, ils pouvaient aussi comprendre l’impact énergétique de leurs services. Nous avons trouvé cela utile pour faire passer la discussion d’objectifs abstraits de durabilité à des choix d’ingénierie spécifiques, comme le dimensionnement adéquat des charges, la réduction des traitements en arrière-plan inutiles et l’amélioration de portions de code inefficaces.

Transformer le cycle de vie de l’application et de la plateforme

Avec le recul, la leçon la plus importante est qu’une IDP devient beaucoup plus précieuse lorsqu’elle reflète le flux de travail réel des équipes qui exploitent la plateforme. En mettant l’accent sur les ingénieurs en automatisation et les SRE, nous avons amélioré les fondations dont dépendent les équipes applicatives. Les scripts pouvaient être générés plus vite, testés de façon plus sécuritaire, réutilisés plus uniformément et observés avec un meilleur contexte.

Le résultat n’a pas été une transformation soudaine causée par un portail. Il s’agit plutôt d’une amélioration constante de la gestion des environnements, des opérations de livraison et de l’automatisation de l’infrastructure. Les équipes applicatives en ont profité parce que les équipes plateforme ont eu accès à de meilleurs outils. Les équipes plateforme en ont profité puisque leur travail est devenu plus standardisé et plus facile à valider. Pour nous, c’est la véritable valeur d’avoir repensé l’IDP : la rendre utile pour ceux qui assurent discrètement la poursuite des livraisons au quotidien.