Déplacer une machine virtuelle chez un fournisseur peut éviter un achat ou accélérer un environnement. L’application ne devient pas élastique parce que son serveur porte un autre logo. Pour ajouter et retirer des instances, elle doit accepter que chacune soit temporaire.

L’état de session en mémoire, les fichiers sur le disque local et une tâche planifiée sur une seule machine attachent le service à cette instance. Je déplacerais session vers un dépôt partagé, fichiers vers un stockage durable et travaux vers une file. Les frontaux deviennent alors interchangeables derrière un répartiteur.

Une montée en charge mesurable

Le flux peut être :

1. le répartiteur reçoit les requêtes;
2. une probe retire les instances non prêtes;
3. chaque frontal lit la session partagée;
4. les travaux longs entrent dans une file;
5. une métrique mesure CPU, latence et profondeur de file;
6. une règle ajoute des instances après plusieurs minutes de seuil;
7. les instances retirées terminent leurs requêtes avant arrêt.

Scaler sur le CPU seul peut se tromper. Un service bloqué sur SQL affiche peu de CPU tout en répondant lentement. Pour les workers, l’âge du plus vieux message et le débit donnent un meilleur signal. Ajouter cent frontaux ne corrige pas une base saturée.

Le démarrage prend du temps. Une image doit être à jour, la configuration externe et l’instance prête avant de recevoir le trafic. Les secrets sont injectés par un mécanisme de gestion, pas intégrés à l’image. La version déployée est immuable et peut être remise en arrière.

La panne normale doit rester locale

Une zone, un service DNS ou une dépendance peut tomber. Deux instances sur le même hôte ne suffisent pas. Répartir selon les domaines de panne, répliquer les données et tester la bascule réduit le risque. La réplication asynchrone implique un RPO; la synchrone ajoute latence et peut sacrifier la disponibilité pendant une partition.

Les appels sortants possèdent timeout, quelques reprises avec attente et disjoncteur. Une opération d’écriture porte une clé idempotente. Les logs et métriques quittent les instances, sinon ils disparaissent pendant le remplacement. Une alerte doit suivre le service utilisateur, pas le nombre de VM.

Le coût devient une boucle. Les ressources portent propriétaire et centre de coût; une limite minimale protège le service et une limite maximale protège la facture. Une hausse automatique doit pouvoir être expliquée par la charge.

Tester la montée et la descente séparément

Ajouter des instances est facile à observer; les retirer peut couper un traitement. Je marquerais une instance draining, la retirerais du répartiteur, attendrais les requêtes actives et remettrais ses messages non confirmés dans la file. Un délai maximum protège contre un travail bloqué. Les connexions persistantes et WebSockets demandent une stratégie propre, par exemple prévenir le client et reconnecter ailleurs. Après arrêt, une réconciliation vérifie qu’aucun identifiant n’est resté en cours. Cette séquence est testée pendant une baisse de charge artificielle. Une élasticité sûre sait rendre la capacité, pas seulement la louer lorsque le graphique monte.

Je tuerais une instance en pleine activité, couperais une dépendance et doublerais la demande. Si le travail continue, l’état est récupérable et les signaux racontent la transition, le cloud apporte autre chose qu’un nouvel emplacement. L’élasticité se prouve en perdant volontairement une machine.