La plupart des discussions sur l’ingénierie de plateforme et les plateformes de développeurs internes (IDP) commencent avec un objectif familier : réduire la charge cognitive des développeurs de logiciels.
C’est un objectif valable et c’est généralement là que commencent les conversations sur les IDP. Cependant, lorsque nous avons commencé à travailler sur des plateformes de calibre entreprise, nous avons vu un problème différent émerger très rapidement.
La plus grande friction n’était pas seulement chez les développeurs d’applications, elle concernait aussi les équipes qui devaient construire, maintenir et automatiser l’infrastructure et les plateformes sur lesquelles tout le monde comptait.
Notre mandat initial était de créer une solution d’ingénierie de plateforme qui inclut les meilleures pratiques, un IDP personnalisable et extensible, ainsi que les compétences appropriées pour gérer tout cela en un seul endroit. Nous avons réussi à créer tout cela en mettant l’accent principalement sur la productivité des développeurs. En même temps, à mesure que nous approfondissions les défis opérationnels quotidiens, nous avons opéré un changement délibéré. Nous avons commencé à considérer les ingénieurs en automatisation, les SRE et les opérateurs d’infrastructure comme des utilisateurs de première classe de la plateforme. Ce changement de perspective nous a aidé à concevoir quelque chose de plus utile, non seulement un catalogue, mais un environnement de travail où les équipes plateforme pouvaient créer, tester, gouverner et exploiter l’automatisation de façon plus cohérente. Nous avons en fait réorienté l’ensemble de la solution d’ingénierie de plateforme pour les ingénieurs de plateforme, les ingénieurs des opérations d’infrastructure, les SRE, les ingénieurs de fiabilité réseau, etc. Maintenant, les mêmes concepts d’ingénierie de plateforme destinés aux développeurs de logiciels sont appliqués aux automatisations et aux développeurs liés à la GenAI, mais spécifiquement pour le provisionnement, les mises à niveau et les automatisations des opérations 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 plateformes middleware et des opérations applicatives est dispersée. Nous avons vu des scripts dans différents dépôts, des infrastructures sous forme de code exécutées à partir de machines individuelles, et les connaissances sur les versions d’applications et de plateformes détenues par quelques ingénieurs expérimentés. Rien de tout cela n’était dû à une mauvaise intention. C’était simplement le résultat d’équipes qui ont réglé des problèmes urgents au fil du temps sans modèle opérationnel commun. L’impact devenait visible dès qu’une équipe applicative avait besoin d’un nouvel environnement, d’une mise à jour du pipeline de livraison ou d’un changement de configuration. La demande se transformait généralement en billet et l’attente commençait.
Ce qui nous est apparu clairement, c’est que le délai n’était que rarement une question de capacité. Les équipes d’opérations applicatives savaient ce qu’elles faisaient. Le véritable problème était que chaque changement nécessitait trop d’efforts manuels, trop de changements de contexte et trop de vérifications minutieuses. Si nous voulions améliorer les cycles de livraison applicative, nous devions d’abord améliorer le flux de travail quotidien des ingénieurs qui construisaient et supportaient ces pipelines de livraison. La solution HCL IDP est devenue l’endroit où nous avons rassemblé ce flux de travail.
L’introduction de l’ingénierie de plateforme et de l’IDP pour les plateformes s’est avérée être une bouée de sauvetage dans les opérations applicatives. Maintenant, les cycles critiques de livraison applicative sont gérés grâce à des automatisations en un clic. Et tous les scripts d’automatisation sont conservés dans GitHub, avec des modèles de base accessibles via l’IDP, la réutilisabilité a bondi, réduisant considérablement le temps de réalisation.
Personnaliser Backstage pour AppOps et la gestion de plateformes
Notre solution IDP est basée sur Backstage et Backstage est performant pour cataloguer les services et les composants logiciels, mais nous avions besoin qu’il représente les actifs que nos équipes AppOps et de plateforme utilisaient réellement chaque jour.
Nous avons élargi le catalogue pour inclure les modules Terraform, les modèles de pipeline CI/CD, des scripts opérationnels, des charts Helm, des configurations types et des définitions de politiques sous forme de code. Cela a donné aux ingénieurs un endroit unique pour trouver les actifs d’automatisation approuvés au lieu de chercher dans plusieurs dépôts ou de demander la dernière version.
Ce petit changement a augmenté l’utilité de la plateforme. Les ingénieurs en automatisation pouvaient voir ce qui existait déjà, comprendre les dépendances, consulter l’historique d’exécution et réemployer des modèles avec plus de confiance. Au fil du temps, cela a aussi diminué le nombre de solutions ponctuelles créées pour les mêmes exigences d’environnement et de livraison.
HCL IDP : génération de code guidée par l’IA incluse
La solution HCL IDP, dans le cadre du cadre CARE, a été considérablement modifiée et de nombreuses fonctionnalités additionnelles ont été ajoutées ces dernières années. Toutes ces fonctionnalités additionnelles sont basées sur les commentaires des clients et sur des évolutions techniques majeures.
L’une des ajouts les plus pratiques que nous avons faits a été un assistant alimenté par l’IA au sein de l’expérience IDP. Nous ne l’avons pas positionné comme un remplaçant au jugement des ingénieurs. Nous l’avons plutôt utilisé pour éliminer une partie de l’effort répétitif lié à l’écriture du code d’automatisation et de configuration de la plateforme. Les SREs d’AppOps revoyaient, ajustaient et validaient toujours la sortie, mais le point de départ était beaucoup plus rapide.
L’assistant a été calibré selon nos modèles d’architecture interne, nos attentes de sécurité et notre outillage privilégié. Par exemple, lorsqu’un ingénieur avait besoin d’un manifeste Kubernetes, d’un playbook Ansible ou d’un chart Helm pour un scénario de livraison spécifique, l’assistant pouvait générer une ébauche conforme à nos standards. Le vrai bénéfice n’était pas que l’IA écrivait le code. L’avantage était que les ingénieurs passaient moins de temps à produire du code générique et plus de temps à réfléchir aux risques, aux dépendances et à l’impact opérationnel.
Modèles de déploiement rapide de plateformes
Nous avons aussi appris que générer du code d’automatisation n’est que la moitié du problème. La question la plus importante est : où le tester en toute sécurité? Auparavant, les ingénieurs avaient souvent un accès limité à des environnements de test réalistes, et valider un changement d’infrastructure demandait la coordination de plusieurs équipes. Cela engendrait de l’hésitation, surtout pour les changements impliquant le réseau, des migrations de bases de données, des politiques de cluster ou des services partagés sur la plateforme.
Pour régler cela, nous avons introduit des modèles de déploiement de plateforme à l’intérieur de l’IDP. Il ne s’agissait pas de simples modèles applicatifs. Ils étaient conçus pour une validation au niveau plateforme et notre solution-phare ePACE a servi de catalyseur. Un ingénieur pouvait créer un environnement Kubernetes éphémère avec la pile standard de la plateforme, y appliquer un nouveau script ou une nouvelle configuration, observer le comportement puis démonter l’environnement une fois les tests terminés. Tout cela à travers ePACE qui fonctionne en arrière-plan dans 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 vérification ou de contrôle du changement, mais cela a réduit la crainte de tester des changements d’infrastructure. Les ingénieurs pouvaient valider le comportement dans un environnement beaucoup plus proche de la production réelle, sans mettre en danger des charges de travail actives. Le nettoyage automatique a également permis d’éviter le problème récurrent des environnements de test oubliés et laissés en marche indéfiniment.
Observabilité en temps réel pour une 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 pipelines pour comprendre si un changement s’était bien déroulé. Ce changement de contexte ralentissait le dépannage et compliquait le lien entre une action de déploiement et son impact opérationnel.
Nous avons intégré les vues clés d’observabilité dans HCL IDP, pour que les équipes puissent voir l’utilisation des ressources, la latence, les taux d’erreurs et la santé de l’environnement au même endroit où elles initient ou examinent des 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 détecter le signal rapidement et réagir avec un meilleur contexte.
Faire avancer les GreenOps grâce à des tableaux de bord durables
À mesure que la plateforme a mûri, nous avons aussi commencé à regarder au-delà de la rapidité et de la fiabilité. Le coût et la durabilité sont devenus des aspects essentiels. Nous avons intégré Kepler, l’outil Kubernetes-basé d’exportation efficace du niveau de puissance, pour donner aux équipes une visibilité sur les tendances de consommation énergétique au niveau des charges de travail. C’était utile parce que cela reliait l’efficacité de l’infrastructure aux choix de conception applicative.
Pour les développeurs, cela rendait l’efficacité plus visible. Au lieu de voir seulement des chiffres de CPU et de mémoire, ils pouvaient aussi comprendre l’impact énergétique de leurs services. Cela nous a aidés à faire passer la discussion de buts abstraits de durabilité vers des choix d’ingénierie concrets, comme ajuster la taille des charges, réduire le traitement inutile en arrière-plan et améliorer les chemins de code inefficaces.
Transformer le cycle de vie des applications et de la plateforme
Avec le recul, la leçon la plus importante a été qu’une IDP devient beaucoup plus précieuse lorsqu’elle reflète le vrai flux de travail des équipes qui opèrent la plateforme. En mettant l’accent sur les ingénieurs en automatisation et les SRE, nous avons amélioré la base sur laquelle les équipes applicatives s’appuient. Les scripts pouvaient être générés plus rapidement, testés en toute sécurité, réutilisés plus systématiquement et observés dans un meilleur contexte.
Le résultat n’a pas été une transformation subite déclenchée par un portail. Il s’est plutôt traduit par une amélioration progressive de la gestion des environnements, des opérations de mise en production et de l’automatisation de l’infrastructure. Les équipes applicatives en ont profité car les équipes plateforme avaient de meilleurs outils. Les équipes plateforme en ont profité car leur travail est devenu plus standardisé et plus facile à valider. Pour nous, c’était la vraie valeur de repenser l’IDP : la rendre utile aux personnes qui, discrètement, gardent la machine de livraison en marche.
