200 Instances Jenkins sur le Cloud : Comment les offrir sans se ruiner !

Comme nous vous l'avions présenté dans un précédent article (immanquable mais just in case : it's here !), nous avons réussi à dompter la complexité de la gestion de plus de 200 instances Jenkins grâce à une approche GitOps avec FluxCD.

Un socle technique stable et apprécié de nos équipes était en place.

Cependant ce succès avait un coût tangible : une enveloppe d'infrastructure annuelle à six chiffres, prix catalogue. Chaque instance, avec sa JVM dédiée et ses ressources, contribuait à cette note, 24/7.

La question n'était plus "Est-ce que cela fonctionne ?" mais "Est-ce que cela fonctionne de manière efficiente ?".

Certains nous suggéraient la solution de facilité : imposer des plafonds de ressources CPU et mémoire drastiques. Nous avons rejeté cette approche. Elle allait à l'encontre de notre promesse fondamentale : rendre les équipes autonomes et efficaces, sans compromis.

Dégrader l'expérience de nos utilisateurs n'a jamais été une option.

Notre approche fut donc différente. Nous devions faire preuve d'élégance technique pour aligner nos dépenses sur la valeur réellement consommée. Ainsi, nous avons embrassé une démarche FinOps, non pas comme un exercice comptable, mais comme une discipline d'ingénierie.

Notre première cible était l'évidence même : les instances inactives. Pourquoi 200 contrôleurs Jenkins devaient-ils consommer des ressources en pleine nuit ou le week-end ? Réponse simple : ils ne le devaient pas. Pour y parvenir, notre arme de choix fut KEDA (Kubernetes Event-driven Autoscaling) et son http-add-on.

Sa mise en œuvre à notre échelle fut avant tout une aventure humaine, avec une campagne de conduite du changement massive : communication proactive dans nos communautés tech, démonstrations, présentations en Townhall et support de proximité. Nous avons aussi dû adapter notre monitoring pour ne pas réveiller nous-mêmes nos instances en permanence.

Le résultat fut une transition d'une fluidité remarquable, validée par un canal de support quasi silencieux : moins de 10 tickets liés à ce changement majeur ont été ouverts. L'impact sur la facture, lui, a été immédiat : cette seule optimisation a réduit de 30% notre dépense annuelle ! Non négligeable !

Notre facture annuelle théorique avoisinant désormais les 5 chiffres, nous voulions rendre chaque utilisation la moins chère et la plus rapide possible.

Notre première optimisation fut architecturale, avec le passage de nos contrôleurs Jenkins sur des processeurs ARM. Le workload est un candidat idéal pour cette architecture, appliqué à notre nouvelle base, ce changement a encore réduit la facture de près de 25 %.

Puis, nous nous sommes attaqués à la latence avec un cache partagé via NFS. Son impact financier direct est limité, mais sa véritable valeur est dans le temps rendu à nos développeurs. Faisons un calcul simple : si 500 développeurs lancent 10 builds par jour et que le cache leur fait gagner ne serait-ce que 2 minutes par build, nous économisons 10 000 minutes chaque jour. C'est plus de 20 jours-hommes de productivité récupérés... quotidiennement. Nous laissons au lecteur le soin de multiplier ce chiffre par son taux journalier moyen pour mesurer la magnitude de l'impact. Chers lecteurs, nous vous laissons le soin de multiplier ce chiffre par son taux journalier moyen pour mesurer la magnitude de l'impact 😉

Une plateforme efficiente ne peut compenser un pipeline inefficace. Le dernier kilomètre de l'optimisation se trouvait dans les Jenkinsfile. Pour cela, nous avons développé un plugin Jenkins interne qui publie des métriques sur chaque build via Kafka et Elasticsearch.

Grâce à nos dashboards, nous travaillons avec les équipes pour identifier des "mauvaises pratiques" : cronjobs trop fréquents, builds bloqués, etc. Mais le gain le plus direct fut opérationnel. Chaque nuit, un ou deux builds "zombies", bloqués en attente d'une action, suffisaient à empêcher notre flotte de runners de s'éteindre complètement. Grâce à cette métrologie, nous les identifions et les arrêtons en quelques minutes.

Résultat : nos runners peuvent désormais atteindre un véritable scale-to-zero, générant des économies substantielles sur les ressources de calcul les plus coûteuses.

Ce parcours nous a enseigné une leçon fondamentale : le FinOps n'est pas une simple couche de reporting financier appliquée sur la technique. C'est une discipline d'architecture à part entière.

En passant d'une facture théorique à six chiffres et en la diminuant de moitié, tout en rendant des milliers d'heures de productivité à nos équipes, nous avons prouvé qu'il est possible de concilier sobriété et performance.

En refusant la solution facile de la dégradation de service et en choisissant la voie de l'optimisation intelligente, nous avons construit une plateforme non seulement plus économique, mais aussi plus performante et plus résiliente.

La vraie performance, c'est quand l'élégance technique rencontre l'efficience économique. Et c'est une mission qui ne fait que commencer. Affaire à suivre...