Dans cet article
Un petit service et une plateforme coûteuse
Imaginons une équipe avec une application web, un traitement asynchrone et une base. Les déploiements sont peu fréquents, mais l’entretien du cluster et de la CI mobilise plusieurs jours. La discussion doit commencer par ce déséquilibre. Un hébergement applicatif managé couvrirait-il les exigences de disponibilité, réseau et déploiement ? Quelle capacité disparaîtrait en simplifiant ?
Changeons de situation : plusieurs équipes publient à des rythmes différents, les traitements demandent des ressources distinctes et les politiques doivent être appliquées uniformément. L’orchestration peut devenir utile. La différence est un besoin d’exploitation, pas un seuil d’utilisateurs. Kubernetes décrit une plateforme de gestion de charges conteneurisées ; son adoption ne fournit ni organisation d’astreinte, ni plan de reprise, ni connaissance de votre application.
Commencer par les critères de promotion
Kubernetes n’est pas un badge de maturité. Nommez les contraintes qu’un déploiement plus simple ne couvre plus : isolation, scalabilité indépendante, scheduling, politiques, responsabilité multi-équipe ou reprise.
Jenkins est également un produit à exploiter. La CI existante peut déjà fournir build, approbation, artefacts et déploiement sans ajouter un contrôleur et une surface de plugins séparés.
Évaluer la surface d’exploitation
Incluez mises à jour du cluster et du contrôleur, identité, politiques réseau, secrets, observabilité, capacité, sauvegardes, incidents et personnes responsables. Le coût d’infrastructure seul ne décide pas.
Si aucun responsable ne peut répéter une restauration, faire tourner les secrets et diagnostiquer un rollout en échec, la frontière plateforme devance l’organisation.
Que doit justifier la plateforme ?
Comparer les responsabilités d’exploitation avant d’ajouter de l’infrastructure.
Socle plus simple
Une surface de déploiement réduite, avec moins de composants à maintenir.
Investissement plateforme
Des capacités supplémentaires de déploiement, mais aussi mises à jour, incidents et responsabilités.
Preuves de décision
Une contrainte réelle, un responsable identifié et un plan de reprise.
Utiliser une décision de promotion réversible
Définissez des déclencheurs mesurables et la baseline plus simple. Ne promouvez que les workloads qui ont besoin de la capacité, conservez un rollback d’artefact et vérifiez que la couche ajoutée résout bien la contrainte.
Le relevé de décision doit aussi préciser ce qui conduirait à revenir vers un service managé ou un runtime plus simple.
Séparer la décision CI de celle de l’hébergement
Une chaîne CI produit et vérifie un artefact. L’environnement d’exécution démarre et exploite cet artefact. Choisir Kubernetes n’impose pas Jenkins ; conserver Jenkins n’impose pas Kubernetes. Évaluez chaque choix selon ses contraintes : réseau privé, chaînes existantes, approbations, isolation des builds et compétences disponibles pour la maintenance.
Pour un essai de migration, conservez la même image applicative et déployez-la par le chemin candidat. Répétez un contrôle de santé échoué, une dépendance indisponible et une erreur de configuration. Notez les commandes et décisions nécessaires à la reprise. Une plateforme qui accélère un déploiement réussi mais rend le diagnostic inaccessible à l’équipe produit peut déplacer le blocage plutôt que le supprimer.
Un bilan reproductible après la migration
Tenez un relevé du travail plateforme : mises à jour, changements d’accès, incidents de déploiement et assistance aux équipes. Comparez-le à l’approche précédente, avec le temps de reprise applicative et les difficultés de livraison. Examinez les cas extrêmes, pas seulement les moyennes : une restauration impossible peut peser davantage qu’un petit gain de vitesse quotidien.
Désignez un responsable de la feuille de route et une date de réexamen. Si la plupart des applications n’utilisent pas les capacités ajoutées, regroupez-les. Si les contrôles communs réduisent réellement le travail répété, investissez dans documentation et modèles maintenus. La plateforme devient un service interne avec des utilisateurs et des coûts, plutôt qu’une infrastructure dont l’existence se justifie elle-même.
Sources et lectures complémentaires
Documentation consultée le .
FAQ / DÉCISIONS
Questions fréquentes
Une architecture microservices exige-t-elle Kubernetes ?+
Non. Topologie de déploiement et frontières applicatives sont deux décisions distinctes. Choisissez l’orchestration uniquement pour des capacités que le modèle d’exploitation peut porter.