Stratégie & migration cloud
Déplacer une application est facile. Décider lesquelles méritent de partir, lesquelles doivent d'abord être réécrites et lesquelles peuvent simplement être retirées, voilà ce qui décide si la facture baisse ou monte.
Une migration est un arbitrage, pas un déménagement.
Six migrations sur dix rendent moins que prévu, et la première raison est toujours la même : un monolithe déplacé sans changement garde ses défauts et paie désormais une réservation permanente là où il tournait sur du matériel déjà amorti.
Nous partons donc de l'inventaire plutôt que de la cible. Chaque charge reçoit sa propre stratégie, retrait compris, et chaque vague est suivie quatorze jours après la bascule. Une migration qu'on ne mesure pas après coup est une migration dont personne ne connaît le résultat.
Ce que nous faisons
Quatre chantiers pour que ce qui part soit décidé par la valeur et non par la facilité.
Inventaire et stratégie par charge
Chaque charge reçoit son chemin : réhéberger, replateformer, réécrire ou retirer, avec la raison écrite à côté. Retirer est une stratégie, et c'est souvent la moins chère.
l'arbitrage se négocie sur le fichier, il ne se découvre pas pendant la fenêtre
- Avec ou sans état, et ses dépendances
- Une stratégie par charge, avec sa raison
- Ce qui n'a plus d'usage ne part pas
Terrain d'atterrissage
Réseau, zones de disponibilité, chiffrement, journalisation et étiquettes obligatoires sont posés avant l'arrivée de la première charge. Ce qui n'y figure pas devient une exception à défendre.
résidence et garde-fous posés à la création, pas vérifiés après coup
- Des garde-fous qui refusent à la création
- Étiquettes obligatoires : équipe, environnement, charge
- Journalisation séparée des comptes qu'elle surveille
Vagues et bascule
Une vague se prépare comme une opération : gel des changements, répétition en préproduction dont une avec le repli, puis bascule progressive avec contrôles à chaque palier.
le plan de repli s'écrit avant la fenêtre, jamais pendant
- Gel des changements et repli répété
- Bascule progressive : 10 %, 50 %, 100 %
- L'ancien environnement maintenu chaud
Mesure après bascule
Latence, erreurs et coût sont comparés pendant quatorze jours à la situation précédente, charge par charge. L'ancien environnement n'est éteint qu'après cette période.
une charge qui coûte plus cher après la bascule repart en arbitrage
- Latence et erreurs face à la référence
- Coût rattaché à la charge, pas au compte
- Extinction seulement après la comparaison
Ce que vous recevez
Un même projet traverse les quatre livrables ci-dessous : la migration du socle applicatif d'un groupe vers du Kubernetes managé, soixante-quatre charges sur neuf mois. Chaque ligne dit ce qui est réellement remis, dans l'ordre où on le remet.
L'inventaire, et une stratégie par charge
Le fichier qui se négocie avant que rien ne bouge : état, dépendances, stratégie retenue et sa raison. Sur ce parc, neuf charges sortent complètement de la migration, faute d'usage.
Le terrain d'atterrissage, décrit en code
Régions, zones de disponibilité, réseau privé, chiffrement obligatoire, stockage public interdit et étiquettes imposées. Une région hors Union européenne est refusée à la création, pas signalée dans un audit trois mois plus tard.
La vague et son plan de repli
Gel des changements quarante-huit heures avant, bascule répétée deux fois en préproduction dont une avec le repli, bascule DNS progressive, et un déclencheur de retour écrit comme un seuil plutôt que laissé au jugement.
Les quatorze jours qui suivent
Erreurs, latence et coût comparés à la situation précédente. C'est là qu'une charge déplacée sans changement montre ce qu'elle coûte vraiment, pendant que l'ancien environnement est encore chaud et la décision encore réversible.
Comment on livre
Inventorier
selon le nombre de charges, de dépendances et de contraintes de résidence
- Inventaire et dépendances par charge
- Une stratégie par charge, retrait compris
- Trajectoire chiffrée et coûts modélisés
Première vague
selon le terrain d'atterrissage à poser et les charges retenues
- Terrain d'atterrissage décrit en code
- Bascule répétée, repli éprouvé
- Quatorze jours de comparaison avant extinction
Vagues suivantes
selon le nombre de charges restantes et leur couplage
- Vagues suivantes sur le même gabarit
- Charges réécrites quand le déplacement ne suffit pas
- Montée en compétences des équipes
Exploiter
engagement de service défini avec vous
- Coût rattaché à la charge et suivi
- Garde-fous tenus à la création
- Réversibilité éprouvée, pas déclarée
Ce que rendent vraiment les migrations
Des migrations menées au bout
Une fabrique digitale reconstruite cloud-native sur Azure
100 % d'infrastructure en Terraform · −24 % sur la facture cloud
Un groupe de 7 000 collaborateurs dont les applications se déployaient à la main, avec des environnements qui divergeaient les uns des autres et une facture cloud que personne ne rattachait à une équipe.
Une fabrique cloud-native sur Kubernetes managé, avec l'infrastructure entièrement décrite en Terraform et répartie sur trois zones de disponibilité. Le temps de déploiement divisé par six, et une facture qui baisse au lieu de monter.
Une chaîne de déploiement qui se rejoue, sur Azure
230 pipelines industrialisés · 0 vulnérabilité critique
Des déploiements et des flux de données menés sans chaîne commune : chaque changement rejoué à la main, et rien qui garantisse que deux environnements se comportent pareil.
Une chaîne DevOps et DataOps bâtie sur Azure : environnements décrits en code, pipelines industrialisés, contrôles de sécurité intégrés à la chaîne plutôt que passés à la fin.
Insights & Perspectives
Introduction à l'orchestration de conteneurs
Une application d'entreprise peut compter des milliers de conteneurs impossibles à gérer à la main : ce que l'orchestration prend en charge, et ce qu'elle ne règle pas.
Terraform : la configuration backend partielle à l'échelle
Séparer ce qui est statique de ce qui est dynamique supprime la duplication, garde les secrets hors du dépôt et fait tenir l'automatisation sur de nombreux environnements.
Bonnes pratiques Kubernetes en production
Limites de ressources, sondes, stratégie de déploiement et quotas : ce qui sépare un cluster qui tient d'un cluster qui fonctionne jusqu'au premier pic de trafic.
Décidez ce qui part avant de le déplacer
Un inventaire, une stratégie par charge, un terrain d'atterrissage décrit en code, et une première vague mesurée quatorze jours.
Questions fréquentes
Parce qu'un monolithe déplacé sans changement conserve tous ses défauts et paie maintenant une réservation permanente. Six sur dix rendent moins que le retour attendu, principalement pour cette raison, et parce que les coûts cachés, sortie de données, licences, support, n'avaient pas été modélisés.
Celles qui gagnent quelque chose au déplacement : trafic variable, chaîne de dépendances isolée, technologie déjà supportée par la cible. Une charge très stateful au cœur monolithique gagne peu et paie le plus : elle passe en vague ultérieure, ou se réécrit d'abord.
À poser le terrain avant l'arrivée de la première charge : réseau, zones, chiffrement, journalisation et étiquettes obligatoires. Son intérêt est de refuser à la création plutôt que de signaler après coup, ce qui fait toute la différence entre un garde-fou et un constat d'audit.
En répétant le repli avant la fenêtre, pas en l'écrivant. La bascule est progressive, l'ancien environnement reste chaud, et le déclencheur de retour est un seuil, un taux d'erreur ou une latence, plutôt qu'un jugement rendu à trois heures du matin.
Après quatorze jours de comparaison, pas le jour de la bascule. Ces deux semaines sont ce qui révèle une charge devenue plus chère qu'avant, et elles ne servent que si l'environnement précédent est encore disponible pour y revenir.
Non, et forcer le passage coûte en général plus qu'il ne rapporte. Le placement d'une charge suit ses contraintes, résidence, latence, licences existantes, plutôt qu'une préférence pour un fournisseur unique. Ce qui doit rester uniforme, c'est la chaîne de déploiement, pas la destination.
Le cadrage prend 2 à 6 semaines selon le nombre de charges, de dépendances et de contraintes de résidence, et produit l'inventaire, une stratégie par charge et une trajectoire chiffrée. La première vague arrive en 4 à 10 semaines, terrain d'atterrissage compris, et c'est elle qui dit si la suite du plan tient.