Un portail tourne sur un serveur avec Docker Compose. Après une panne de quarante minutes, la direction demande Kubernetes. Une autre équipe propose une plateforme managée qui promet de supprimer l’exploitation. Le problème est de confondre le symptôme avec la solution : les trois options relancent des conteneurs, mais aucune ne décide quelles pannes absorber, qui garde la responsabilité et quel délai le métier accepte.
Le vrai enjeu consiste à acheter le bon niveau d’autonomie opérationnelle. Compose orchestre correctement plusieurs services sur un hôte. Une PaaS délègue une partie du build, du déploiement et de la plateforme. Kubernetes fournit une API de contrôle distribuée, riche mais exigeante. Le choix devient rationnel seulement après avoir décrit disponibilité, variations de charge, état, sécurité et équipe de run.
Paradoxalement, l’option la plus automatisée peut créer le plus de travail. Autoscaling, opérateurs, politiques réseau et charts ne suppriment pas les incidents applicatifs ; ils ajoutent des contrats à surveiller. Une architecture plus simple, soutenue par une restauration répétée et un fournisseur adapté, peut offrir une continuité supérieure à un cluster que personne ne sait mettre à jour.
Pour un produit construit en développement web sur mesure, la décision doit partir des flux et du run. L’arbitrage s’appuie sur des critères éliminatoires, un cas B2B, des seuils locaux et un pilote qui compare les options sans faire de Kubernetes une récompense de maturité ni de la plateforme managée une boîte noire.
Partir de la contrainte plutôt que de l’orchestrateur
Écrire la conséquence d’une interruption
Le comité liste les services rendus, les périodes sensibles et les conséquences d’un arrêt. Une indisponibilité de dix minutes sur un catalogue interne n’a pas le même poids qu’un blocage de paiement. Il décide RTO, perte de données tolérée, mode dégradé et personne autorisée à arrêter un flux. Ces paramètres deviennent des entrées d’architecture, pas des promesses ajoutées au contrat après le choix.
Il distingue ensuite panne de processus, hôte perdu, zone indisponible, erreur de déploiement et fournisseur externe silencieux. Kubernetes peut remplacer un Pod, mais ne répare pas un schéma incompatible ni une facture dupliquée. Compose peut redémarrer un service, mais un hôte unique reste un domaine de panne. La PaaS peut gérer l’hôte tout en laissant l’application responsable de ses données.
Refuser la liste de fonctionnalités
Une grille qui compte autoscaling, service discovery et rolling update avantage mécaniquement la solution la plus riche. La comparaison utile demande plutôt comment chaque option traite le scénario précis, quelles responsabilités restent internes et comment le rollback est exécuté. Une fonction non reliée à une contrainte ajoute du coût sans preuve de valeur.
Inventorier les workloads et leurs promesses
L’application n’est pas un bloc. Le web sert des requêtes courtes, les workers consomment des messages, le cron déclenche des travaux planifiés et un import peut saturer CPU ou base. Chaque workload possède commande, dépendances, concurrence, état, délai et comportement d’arrêt. Cette carte révèle si les composants doivent réellement être dimensionnés et déployés séparément.
Un service stateless est remplaçable si session, fichiers et cache utile vivent ailleurs. Un worker n’est pas stateless parce qu’il redémarre : sa file, son acquittement et ses effets externes portent l’état. Le pilote documente donc messages en vol, idempotence, stockage et source de vérité avant de promettre qu’un orchestrateur rend tout élastique.
Identifier les dépendances hors plateforme
Base managée, stockage objet, fournisseur de mail, DNS et API partenaires déterminent souvent davantage la disponibilité que le moteur de conteneurs. La matrice associe timeout, quota, sauvegarde, observabilité et procédure de substitution. Un cluster disponible sur trois zones ne compense pas une base unique sans restauration testée.
Connaître la frontière de Docker Compose
Compose décrit services, réseaux, volumes, dépendances et configuration. Sur un serveur unique, il fournit un déploiement lisible et accessible à une petite équipe. La documentation Docker pour Compose en production prévoit des adaptations comme le retrait des bind mounts de code, une politique de redémarrage et une configuration dédiée.
Son avantage est aussi sa limite : l’hôte, le daemon et souvent le reverse proxy forment un domaine de panne commun. On peut restaurer ailleurs avec infrastructure as code et sauvegardes, mais le basculement n’est pas automatique par nature. Le choix reste excellent si le RTO accepte cette reprise et si sa répétition est plus fiable que l’exploitation d’un cluster.
Industrialiser sans imiter Kubernetes
Un registry, des digests, une CI, des healthchecks, des secrets injectés et des sauvegardes testées apportent déjà une grande partie de la discipline. Ajouter un second serveur et des scripts maison d’élection peut en revanche recréer un orchestrateur fragile. Lorsque les besoins dépassent franchement l’hôte, il faut réévaluer le modèle plutôt que multiplier les exceptions.
Mesurer ce que délègue une plateforme managée
Une plateforme managée peut prendre en charge build ou image, routage, certificats, remplacement des instances, logs, métriques et parfois bases. Le gain vient d’un contrat d’exploitation réduit. L’équipe doit lire ce qui est garanti, ce qui reste à configurer, les limites de ressources, le modèle réseau, les régions disponibles et la procédure de sortie.
Le mot « managée » ne signifie pas « sans run ». L’application conserve migrations, files, erreurs métier, capacité, coûts et dépendances. Une plateforme peut redémarrer le conteneur qui échoue sur une configuration invalide sans jamais résoudre la cause. Le runbook doit toujours relier symptômes de la plateforme et statut utilisateur.
Tester la réversibilité du service
Le pilote exporte configuration, image, données et logs nécessaires. Il restaure un environnement minimal ailleurs ou documente le temps et les concessions. Un service propriétaire peut rester rationnel si son gain dépasse ce coût de sortie. Feindre une portabilité gratuite conduit seulement à sous-utiliser les fonctions qui justifient le choix.
Justifier Kubernetes par des besoins indépendants
Kubernetes organise des workloads déclaratifs, leur placement, leur remplacement et leur exposition. Il devient pertinent quand plusieurs équipes et services ont besoin d’un contrôle commun, d’une capacité multi-nœuds, de déploiements progressifs et de politiques cohérentes. Il n’est pas nécessaire pour exécuter trois conteneurs simplement parce que le projet grandit.
La documentation officielle sur un environnement Kubernetes de production rappelle les sujets de haute disponibilité, certificats, etcd, nœuds, accès et ressources. Un service managé délègue le control plane, mais l’organisation reste responsable des workloads, politiques, mises à jour de nœuds selon l’offre et incidents applicatifs.
Exiger une équipe de plateforme ou un produit de plateforme
Des manifests copiés et maintenus par chaque développeur ne créent pas une plateforme. Il faut des chemins standards pour image, déploiement, secret, métrique et rollback, avec une équipe responsable. Sinon, la souplesse de l’API devient une divergence de YAML et chaque mise à niveau du cluster ouvre un projet transverse.
Traduire la disponibilité en architecture
Le SLO décrit une expérience mesurable et une fenêtre. Il évite le mot « haute disponibilité » sans frontière. Le système peut tolérer la perte d’un processus, d’un nœud ou d’une zone selon la réplication, mais chaque niveau ajoute capacité, cohérence, réseau et coût. Le métier choisit la panne réellement couverte.
Le mode dégradé est souvent plus économique qu’une disponibilité totale. Le portail peut accepter une commande et différer l’ERP, servir un catalogue en lecture seule ou suspendre un export. Ces états doivent être conçus dans le produit. Aucun orchestrateur ne devine qu’une facture peut attendre tandis qu’une révocation d’accès ne le peut pas.
Répéter le domaine de panne
Le test coupe un conteneur, puis un nœud ou l’hôte selon la solution. Il observe trafic, messages, session et reprise. Le seuil local peut imposer une page utile sous deux minutes et zéro double effet ; il est lié à ce parcours et sera révisé après mesure, pas présenté comme une norme d’orchestration.
Distinguer pointe, croissance et élasticité
Une croissance prévisible se traite parfois par capacité planifiée. Une pointe brève exige réserve, file ou autoscaling. Un calcul lourd peut être isolé sans déplacer tout le produit. L’équipe mesure CPU, mémoire, connexions SQL, latence externe et profondeur de file ; augmenter les replicas web ne corrige pas une base saturée.
L’autoscaling réagit après un signal et possède un délai. Une campagne qui multiplie le trafic en vingt secondes demande préchauffage ou capacité minimale. Le budget d’erreur tient compte des démarrages, des images à tirer et du cache froid. Kubernetes et certaines PaaS automatisent l’action, mais la métrique et les limites restent une décision locale.
Limiter la concurrence en aval
Dix nouveaux workers peuvent dépasser le quota d’un ERP ou le pool de connexions. La configuration borne débit et concurrence par flux. Une priorité protège les commandes urgentes. Ce contrôle apporte souvent plus de résilience qu’un scaling horizontal déclenché sur le seul CPU.
Traiter données, files et stockage hors slogans
Les conteneurs sont remplaçables ; les données ne le deviennent pas pour autant. Base, objets et messages reçoivent sauvegarde, réplication, chiffrement, rétention et exercice de restauration. Un PersistentVolume Kubernetes attache du stockage selon une classe ; il ne garantit ni cohérence applicative ni reprise multi-région.
La proximité des services influence la latence et les coûts de transfert. Une PaaS avec base intégrée peut simplifier réseau et patching. Un cluster auto-géré donne plus de contrôle mais demande sauvegarde d’etcd et des données applicatives distinctes. Compose sur un hôte peut utiliser une base externe robuste. L’étiquette ne décide pas du niveau de protection.
Séparer restauration et rollback
Le rollback remet une version applicative compatible ; la restauration revient à un état de données et peut perdre des écritures. Les deux procédures ne se substituent pas. Le plan de déploiement protège le schéma pour éviter qu’une erreur de code exige automatiquement une restauration risquée.
Attribuer sécurité, patching et accès
Chaque option déplace la frontière de responsabilité. Sur Compose, l’équipe patche hôte, daemon et application. Sur une PaaS, elle suit le contrat du fournisseur et garde images, dépendances et accès. Sur Kubernetes managé, elle contrôle workloads, RBAC, secrets, politiques et souvent nœuds. La matrice nomme l’owner et le délai de correction.
Le principe du moindre privilège s’applique aux humains et aux workloads. Un pipeline ne reçoit pas un compte administrateur permanent. Les secrets ne vivent pas dans les manifests en clair ni dans l’image. Les journaux d’audit permettent d’expliquer un déploiement et un accès sensible sans enregistrer la valeur secrète.
Préparer la mise à niveau
Le pilote doit inclure un patch de base, une rotation de secret et une version de plateforme. Si personne ne sait faire évoluer le cluster ou si l’offre managée impose une échéance non financée, le coût existe déjà. Une solution tenue sur une version obsolète n’est pas plus sûre parce qu’elle possède davantage de contrôles.
Cas concret : choisir le socle d’un portail B2B
Cas concret hypothétique. Un portail B2B sert deux cents utilisateurs internes, reçoit des commandes par API et lance quatre workers. Les pics mensuels multiplient le débit par cinq pendant trois heures. Une indisponibilité de trente minutes reste acceptable hors clôture ; aucune commande ne doit être dupliquée et le support doit connaître son état.
Compose sur deux procédures de restauration passe le débit mais dépend d’un hôte. Kubernetes couvrirait le nœud et séparerait les workers, mais l’équipe de trois développeurs n’a ni plateforme ni astreinte cluster. Une PaaS accepte les images, les workers indépendants et la base managée, avec un coût supérieur à l’hôte mais inférieur à la création d’une capacité Kubernetes.
Le pilote retient la PaaS pendant six semaines. Les seuils locaux demandent zéro perte sur mille commandes rejouées, un diagnostic sous quinze minutes, une restauration de base prouvée et un coût maximal fixé avant le test. Scénario supplémentaire : si le fournisseur devient indisponible, alors le mode lecture seule doit rester accessible et les commandes en attente doivent repartir sans double effet.
Évaluer la capacité réelle de l’équipe
Le nombre de développeurs ne suffit pas. Il faut disponibilité pour les mises à jour, expérience réseau, sécurité, observabilité et gestion d’incident. Deux personnes doivent savoir déployer et reprendre sans l’auteur de l’infrastructure. Une astreinte qui ne sait qu’escalader au prestataire doit être intégrée au délai promis.
Kubernetes peut être cohérent pour une grande organisation si une équipe plateforme fournit standards et support. Une PaaS est attractive quand l’équipe produit veut déléguer une couche et accepte les limites. Compose reste excellent lorsque le périmètre et le RTO correspondent à un hôte restaurable. L’adéquation se mesure au run, pas au CV technique.
Tester la relève
Une personne non impliquée reçoit alerte, tableau et runbook. Elle retrouve l’image, la configuration et le dernier effet puis exécute une reprise bornée. Si le test exige l’accès personnel du lead, la solution n’est pas exploitable quelle que soit sa sophistication.
Comparer le coût complet du run
Le calcul inclut infrastructure, plateforme, trafic, stockage, observabilité, sauvegarde, sécurité, temps d’équipe et incidents. Un cluster managé facture moins de contrôle plane humain mais pas zéro opération. Une PaaS peut coûter davantage par unité et économiser plusieurs jours de maintenance. Compose réduit la facture directe mais conserve la responsabilité de l’hôte.
Le coût caché le plus fréquent est la coordination. Quand chaque service possède son chart, ses dashboards et sa politique sans standard, une petite évolution mobilise plusieurs équipes. À l’inverse, les limites d’une PaaS peuvent imposer une adaptation applicative. Le comité chiffre les deux plutôt que d’opposer facture cloud et liberté abstraite.
Faire varier les hypothèses
La matrice calcule charge normale, pointe et doublement du produit. Si le verdict change pour une petite variation, le choix nécessite un pilote ou une clause de révision. Si une solution reste nettement adaptée dans les trois cas, la décision devient plus robuste.
Pour qui chaque option devient adaptée
Compose convient à un produit compact, une équipe resserrée et un RTO compatible avec la restauration d’un hôte. La PaaS sert bien une équipe produit qui veut des déploiements, certificats et instances gérés avec des contraintes acceptables. Kubernetes devient pertinent pour plusieurs workloads et équipes nécessitant contrôle, isolation et automatisation communes.
Aucune option n’est obligatoire. Un service serverless, une VM classique ou un hébergement spécialisé peut gagner. Le cadre doit autoriser ce résultat. Fermer la sélection à trois logos alors que le besoin est une application standard hébergée fausse la décision dès le départ.
Erreurs fréquentes dans le choix d’infrastructure
Choisir Kubernetes pour le CV
Le projet finance un cluster sans contrainte multi-nœuds ni équipe de plateforme. Les mises à jour sont différées et le run dépend d’un consultant. La complexité créée dépasse l’autonomie obtenue.
Croire la PaaS sans tester ses limites
Timeout, filesystem, régions ou réseau apparaissent après le développement. Le pilote doit exercer le flux le plus contraint et la sortie des données avant de signer l’architecture.
Faire durer Compose au prix d’un orchestrateur maison
Scripts de bascule, découverte de services et réplication non testée s’accumulent. Dès que le besoin exige une vraie coordination multi-hôtes, la décision doit être rouverte au lieu de cacher la plateforme artisanale.
Construire une matrice de décision éliminatoire
Les critères portent sur domaine de panne, RTO/RPO, charge, état, régions, sécurité, compétences, délai de mise à niveau, réversibilité et coût sur trois ans. Une exigence non négociable élimine l’option ; elle ne se compense pas par des fonctionnalités confortables. Chaque note cite un test, une documentation ou reste une hypothèse.
- D’abord, éliminer toute option qui ne couvre pas le domaine de panne et la restauration décidés.
- Ensuite, prioriser la solution que deux personnes savent déployer, observer et replier.
- Puis, conditionner Kubernetes à un vrai produit de plateforme et la PaaS à une sortie testée.
- Enfin, refuser l’élargissement si données, secrets ou rollback n’ont pas de responsable.
Le verdict peut être « Compose maintenant, révision à tel signal ». Le déclencheur doit être mesurable : deuxième équipe autonome, RTO inférieur à la restauration observée, besoin multi-zone ou saturation indépendante d’un workload. Cette clause empêche une architecture provisoire de devenir définitive par oubli.
Plan d’action pour un pilote comparable
Semaine une : fermer les scénarios
Produit et exploitation définissent trois pannes, le mode dégradé, les seuils et les données à préserver. L’équipe inventorie workloads, dépendances, pics et responsabilités. Elle écarte les options incompatibles avant de construire des démonstrations inégales.
Semaines deux et trois : déployer la même tranche
Chaque option candidate reçoit la même image et le même flux : requête, message, stockage et migration. Le pipeline conserve digest et configuration. Les tableaux affichent latence, erreurs, file et coût. Aucun faux ne remplace la base ou le partenaire difficile.
Semaine quatre : casser et reprendre
Le test tue un processus, coupe le domaine de panne couvert, injecte une migration refusée et restaure une sauvegarde. Le support suit le runbook. Il mesure temps utile, gestes manuels et ambiguïtés, puis vérifie commandes et effets externes.
Semaines cinq et six : mesurer et décider
Un trafic borné observe capacité, incidents, patching et coût. Le comité compare les preuves à la matrice, choisit, conditionne ou refuse. Le dossier attribue monitoring, secrets, upgrades, sauvegarde et rollback avant l’ouverture.
La décision conserve entrées, sorties, dépendances et instrumentation. Elle indique aussi ce qui a été délégué au fournisseur et comment vérifier son respect. Le runbook ne promet pas une action que l’offre ou les droits ne permettent pas réellement.
Après trente jours, une revue confronte coûts prévus, alertes et interventions. Si la plateforme demande davantage de compétences que prévu, le périmètre reste limité. Si les seuils tiennent, l’équipe élargit workload par workload au lieu de migrer tout le patrimoine d’un coup.
Guides complémentaires pour préparer l’exploitation
Stabiliser les images
Partager les conteneurs entre dev, CI et production fixe l’artefact avant de comparer les moteurs qui l’exécutent.
Séparer web, workers et cron
Organiser les services d’une application conteneurisée aide à définir les workloads et leurs arrêts.
Observer la promesse métier
Observer un workflow métier relie santé de plateforme, statut utilisateur et action support.
- Mesurer les domaines de panne avant de noter les fonctionnalités.
- Faire exécuter patch, reprise et rollback par l’équipe réelle.
- Réviser le choix à partir d’un signal de produit, pas d’une mode technique.
Conclusion : acheter la contrainte réellement portée
Compose, PaaS et Kubernetes automatisent des périmètres différents. Leur valeur dépend du domaine de panne, de la charge, de l’état et de la responsabilité que le produit doit réellement porter.
La solution la plus riche n’est pas la plus sûre si l’équipe ne sait ni la mettre à jour ni reprendre un incident. Une option plus simple peut gagner grâce à une restauration éprouvée et des dépendances mieux maîtrisées.
Le bon verdict repose sur une tranche identique, des pannes provoquées et un coût complet. Il peut prévoir une révision lorsque l’organisation, le RTO ou l’autonomie des workloads changent.
Dawap peut cadrer les contraintes, construire le pilote et éprouver le run de l’option retenue dans un projet de développement web sur mesure qui investit dans la continuité utile plutôt que dans une infrastructure décorative.
