L'environnement : une architecture à quatre niveaux sur deux sites
Avant la migration, l'équipe de Software Projects exploitait une architecture unique et bien définie dans deux régions IBM Cloud, dimensionnée pour la résilience : un site principal plus grand et un site secondaire plus petit. Chaque site suivait le même schéma à quatre niveaux :
- Répartition de charge : un petit parc d'instances HAProxy en frontal des trafics de production, de développement et de tracking, gérés séparément.
- Application : des serveurs web et de tracking, un exécuteur de tâches planifiées, un serveur de qualité de code (SonarQube) et une passerelle VPN (présente uniquement sur le site principal).
- Orchestration de conteneurs : des clusters Docker Swarm auto-gérés, exploités en clusters de production et de développement distincts sur le site principal et en un seul cluster sur le site secondaire.
- Données : une paire MySQL primaire/réplica accompagnée d'un cluster Cassandra à trois nœuds, répliqués sur les deux sites.
Le plan de migration de DoiT prévoyait un lift-and-shift fidèle, à l'identique, de cette topologie vers un seul VPC AWS dans us-east-1 — en conservant les mêmes configurations de 24 et 16 nœuds, mais en les répartissant sur plusieurs zones de disponibilité au sein d'une seule région AWS, au lieu de deux régions IBM Cloud indépendantes et géographiquement distinctes. Le tableau ci-dessous montre comment la composition niveau par niveau a été reprise sans changement :
|
| Répartition de charge (HAProxy) | 5 | 5 |
| Application et outillage (web, tracking, tâches planifiées, qualité de code, passerelle VPN) | 6 | 2 |
| Orchestration de conteneurs (Docker Swarm — clusters de production + développement) | 8 | 4 |
| Données (MySQL primaire/réplica + cluster Cassandra à 3 nœuds) | 5 | 5 |
| Total des nœuds | 24 | 16 |
Ces chiffres sont restés constants de part et d'autre de la bascule — les mêmes 24 et 16 nœuds, dans les mêmes proportions niveau par niveau, simplement relocalisés. Cette rigueur a fait toute la différence : Software Projects a ainsi hérité sur AWS d'un environnement se comportant exactement comme celui que son équipe connaissait déjà, tandis que DoiT supprimait discrètement une couche de complexité d'infrastructure en consolidant deux régions de centres de données en une seule région AWS répartie sur plusieurs zones de disponibilité. Cela a également préparé proprement la phase Modernize, la feuille de route prévoyant déjà le retrait des clusters Docker Swarm auto-gérés au profit d'une plateforme de conteneurs managée une fois l'environnement stabilisé sur AWS.
L'approche : AWS MAP, livré de bout en bout
DoiT a mené la mission sur les trois phases de l'AWS MAP, chaque phase posant les fondations techniques et financières de la suivante — le tout livré de bout en bout par l'équipe Forward Deployment Engineering de DoiT.
|
| Objectif | Modélisation des coûts et préparation à la migration | Connectivité inter-cloud et bascule | Conteneurisation et FinOps en continu |
| Statut | Terminée | Terminée | En cours |
1. Assess : construire un budget de migration solide et étayé
Avant tout déplacement de workloads, l'équipe de Software Projects avait besoin d'une vision claire, service par service, du coût du stockage et du calcul sur AWS. DoiT a élaboré une ventilation détaillée des coûts couvrant EBS et EFS — en modélisant les coûts mensuels de stockage, d'IOPS et de débit selon les types de volumes et les classes de stockage — afin que Software Projects puisse prévoir ses dépenses à court et moyen terme pour sa feuille de route de migration. DoiT a également travaillé la stratégie de remises pour le calcul des bases de données de Software Projects, en comparant DoiT Flexsave (un équivalent de Compute Savings Plan à tarif réduit, sans engagement initial) aux tarifs des instances réservées standard et convertibles, et en expliquant les compromis de chaque option dans la perspective d'un éventuel passage futur à un service de base de données managé.
2. Mobilize : résoudre la connectivité inter-cloud
La connectivité entre IBM Cloud et AWS constituait le chemin critique de toute la migration, et il n'existait pas de réponse clé en main. DoiT a mené une évaluation structurée des options — AWS Direct Connect, un circuit dédié IBM Direct Link, des appliances de routeur virtuel et un VPN maillé léger — en pesant pour chacune le coût, la stabilité et la complexité de mise en œuvre :
- Évaluation d'AWS Direct Connect et d'IBM Direct Link Dedicated (y compris les contraintes de BGP, de plages IP et de facturation) comme option de circuit dédié.
- Expérimentation d'un overlay VPN maillé comme solution de repli rapide et sans frais pendant l'évaluation des options de plus long terme.
- Accompagnement de Software Projects dans le déploiement et le réglage d'une appliance de routeur virtuel côté IBM, y compris le comportement de routage VLAN et le dépannage de couche 2 avec le support IBM.
- Aide à la migration de Software Projects d'IBM Classic Infrastructure vers IBM VPC pour gagner en flexibilité réseau, puis mise en place d'un VPN site-à-site IPSec entre IBM VPC et un VPC AWS.
- Diagnostic et résolution d'un chevauchement de sous-réseaux et d'un défaut de routage entre IBM Classic et AWS, en allouant une plage IP dédiée sans chevauchement et en ajustant les routes statiques — le correctif qui a enfin débloqué le trafic bidirectionnel entre les trois environnements.
Le résultat : une liaison réseau privée stable et vérifiée reliant IBM Classic Infrastructure, IBM VPC et AWS — la fondation qui a permis à l'équipe de Software Projects de déplacer ses workloads à son propre rythme, sans perdre la connectivité avec les systèmes encore hébergés chez IBM.
Préserver la stabilité de la production pendant la transition
Pendant la fenêtre de migration, DoiT a également fourni un support opérationnel rapide côté AWS. Dans un cas, une instance EC2 a perdu de façon inattendue sa connectivité SSM, sans repli SSH disponible. DoiT a utilisé les diagnostics de sortie console pour identifier la cause racine — le volume racine était saturé, ce qui empêchait le démarrage de l'agent SSM — et a fourni un plan de remédiation étape par étape (extension du volume et redimensionnement du système de fichiers), accompagné d'alarmes CloudWatch proactives sur l'utilisation disque et de notifications SNS pour éviter que l'incident ne se reproduise, avec une attention particulière portée à la protection des systèmes de production contre ce même mode de défaillance.
3. Modernize : conteneurs et optimisation continue des coûts
La migration achevée, la mission est entrée dans la phase Modernize. Les environnements de production et de développement de Software Projects tournaient encore sur des clusters Docker Swarm auto-gérés — fonctionnels, mais avec la charge opérationnelle de managers et de workers corrigés manuellement. DoiT aide aujourd'hui l'équipe de Software Projects à retirer ces clusters Swarm au profit d'une plateforme de conteneurs managée sur AWS (Amazon EKS), en s'appuyant directement sur la fondation VPC consolidée et multi-AZ établie durant Mobilize, plutôt que de repartir d'une architecture vierge.
Dans le cadre de cette même dynamique de modernisation, DoiT veille à la discipline des dépenses cloud à mesure que l'environnement évolue. À l'aide de DCI Insights, DoiT a passé en revue la configuration AWS Detective et GuardDuty de Software Projects et constaté que les coûts des outils de sécurité représentaient désormais une part significative des dépenses globales, principalement en raison de l'ingestion massive de flow logs plutôt que de la valeur sécurité réellement apportée. DoiT a quantifié les compromis — y compris quels types de findings à haute sévérité dépendaient de quelles sources de données — et fourni à Software Projects un ensemble d'options claires et étayées pour appliquer un right-sizing de la couverture de sécurité sans perdre les détections les plus précieuses. Cette même approche disciplinée, fondée sur les preuves, se poursuit dans le travail de conteneurisation : un right-sizing dès le départ, plutôt qu'une optimisation après coup.
La solution : propulsée par DoiT Cloud Intelligence™ (DCI)
En parallèle du travail d'ingénierie sur le terrain, Software Projects a tiré parti de plusieurs fonctionnalités de DoiT Cloud Intelligence™ (DCI) tout au long de la mission — associant une équipe de delivery expérimentée à une visibilité en libre-service sur son propre environnement AWS :
|
| Forward Deployment Engineering | L'équipe DoiT sur le terrain qui a livré les phases Assess, Mobilize et Modernize de bout en bout — de la conception réseau et de la bascule jusqu'à l'optimisation continue |
| DCI Insights | A fait remonter des recommandations d'optimisation des coûts, dont les options de right-sizing d'AWS Detective et GuardDuty utilisées durant Modernize |
| DCI Cloud Diagrams | A cartographié et visualisé l'infrastructure AWS — la même topologie à quatre niveaux sur deux sites présentée dans la comparaison d'architecture plus haut dans cette étude de cas |
| DCI Datadog Insights | Désormais utilisé en continu par le client pour suivre les dépenses d'observabilité et de monitoring à mesure que l'environnement grandit |
| DCI AWS Intelligence | Désormais utilisé en continu par le client pour suivre l'ensemble des dépenses AWS sur l'environnement consolidé |
Les deux dernières fonctionnalités sont actives au quotidien : à mesure que l'équipe de Software Projects modernise son environnement vers les conteneurs, DCI AWS Intelligence et DCI Datadog Insights lui offrent une visibilité continue sur le total de ses dépenses cloud et d'observabilité, au lieu d'attendre la facture mensuelle pour découvrir un problème.