Kraft.gg - Formations

Appearance

Chapitre 7 : Architecture et migration ​

Cette partie couvre les aspects pratiques : comment concevoir l'architecture et comment exécuter la migration.

Stratégies de migration : vue d'ensemble ​

Les stratégies ont déjà été évoquées, mais elles sont détaillées ici dans le contexte architectural.

Les 7 R de la migration (Gartner) ​

  1. Retire (Retirer)
  2. Retain (Conserver)
  3. Rehost (Lift-and-shift)
  4. Replatform (Lift-and-reshape)
  5. Repurchase (Remplacer)
  6. Refactor/Re-architect (Rearchitecturer)
  7. Rebuild (Reconstruire)

Chaque application du SI doit être évaluée selon ces stratégies.

Rehost : Lift-and-shift ​

Principe ​

Migrer l'application telle quelle, sans modification. VM on-premise → VM cloud (ou équivalent).

Processus typique ​

  1. Inventaire : cartographier l'existant (serveurs, config, dépendances)
  2. Sizing : dimensionner les instances cloud équivalentes
  3. Réplication : tools de migration (AWS Migration Hub, Azure Migrate, CloudEndure)
  4. Cutover : bascule DNS, arrêt source, démarrage cible
  5. Validation : tests fonctionnels et performance

Avantages ​

  • ✅ Rapide : quelques semaines par application
  • ✅ Peu risqué : pas de changement applicatif
  • ✅ Compétences : pas besoin d'expertise cloud profonde
  • ✅ Quick win : montre des résultats rapidement

Inconvénients ​

  • ❌ Pas optimisé : ne tire pas parti du cloud
  • ❌ Coûts : peut être plus cher que l'on-premise (instances sur-dimensionnées)
  • ❌ Dette technique : reporte les problèmes du legacy
  • ❌ Gaspillage : instances qui tournent 24/7 comme avant

Quand l'utiliser ​

  • Applications simples, stateless ou peu critiques
  • Besoin de migrer vite (contrainte temps)
  • Première vague de migration (apprendre)
  • Applications en fin de vie (temporaire avant décommissionnement)
  • Legacy impossible à refactorer à court terme

Outils ​

  • AWS : AWS Application Migration Service (anciennement CloudEndure), AWS Server Migration Service (SMS)
  • Azure : Azure Migrate, Azure Site Recovery
  • GCP : Migrate for Compute Engine
  • Multi-cloud : Carbonite, Zerto
  • Open source : Clonezilla, rsync (basique)

Exemple ​

50 VMs VMware on-premise avec des apps Java/Tomcat migrées vers EC2 ou Azure VMs avec les mêmes specs. Ça tourne, mais le coût est plus élevé et l'agilité n'a pas été gagnée.

Post-migration ​

Prévoir une phase 2 d'optimisation :

  • Right-sizing (ajuster la taille des instances)
  • Auto-scaling
  • Reserved instances
  • Utilisation de services managés (RDS au lieu de DB sur VM)

Replatform : Lift-and-reshape ​

Principe ​

Migrer avec des adaptations mineures pour tirer parti de certains services cloud, sans réécriture majeure.

Exemples de replatform ​

  • Remplacer une base MySQL sur VM par Amazon RDS for MySQL (managé)
  • Passer d'un serveur web classique à un Load Balancer managé
  • Utiliser S3 pour le stockage fichiers au lieu de NAS
  • Conteneuriser l'application (Docker) et déployer sur ECS/AKS au lieu de VMs

Processus ​

  1. Identifier les composants "commoditisables" (DB, cache, queue, storage)
  2. Remplacer par équivalents cloud managés
  3. Adapter la configuration applicative (connection strings, endpoints)
  4. Tester l'intégration
  5. Migrer les données
  6. Déployer et valider

Avantages ​

  • ✅ Bénéfices cloud : haute dispo, scaling, backup automatique
  • ✅ Moins d'ops : services managés réduisent la charge
  • ✅ Effort raisonnable : pas de refonte complète
  • ✅ ROI rapide : gains opérationnels immédiats

Inconvénients ​

  • ❌ Lock-in moyen : dépendance aux services managés
  • ❌ Compatibilité : risque d'incompatibilités mineures
  • ❌ Coût : services managés plus chers que self-hosted (mais moins d'ops)

Quand l'utiliser ​

  • Applications standard avec dépendances classiques (DB, cache, queues)
  • Besoin de réduire la charge ops rapidement
  • Bon compromis effort/bénéfice
  • Équipe avec compétences cloud naissantes

Exemple ​

Application e-commerce :

  • Avant : serveur web + MySQL sur VM + stockage images sur NFS
  • Après : instances EC2/ECS + RDS MySQL + S3 pour images + CloudFront CDN
  • Effort : quelques semaines, gains : haute dispo, backup auto, CDN global

Niveau de refactoring ​

  • Configuration externalisée (12-factor : config via env vars)
  • Utilisation de secrets managés (AWS Secrets Manager, Azure Key Vault)
  • Logging vers service centralisé (CloudWatch, Stackdriver)

Refactor / Re-architect : Cloud-native ​

Principe ​

Réécrire ou refactorer significativement l'application pour adopter une architecture cloud-native : microservices, conteneurs, serverless, event-driven.

Caractéristiques d'une app cloud-native ​

  • Stateless : pas d'état local, session externalisée (Redis, DynamoDB)
  • 12-factor app : principes de portabilité et scalabilité
  • Microservices : décomposition en services indépendants
  • Conteneurisée : Docker + Kubernetes/ECS/Cloud Run
  • API-first : communication REST/gRPC
  • Event-driven : messaging asynchrone (Kafka, SQS, Pub/Sub)
  • Resilient : circuit breakers, retry, graceful degradation
  • Observable : metrics, logs, traces (OpenTelemetry)
  • CI/CD : déploiement automatisé, blue/green, canary

Architectures cibles ​

Microservices sur Kubernetes ​

  • Décomposition du monolithe en services
  • Orchestration K8s (EKS, AKS, GKE)
  • Service mesh (Istio, Linkerd) pour communication inter-services
  • API Gateway (Kong, AWS API Gateway)

Serverless / FaaS ​

  • Lambda functions (AWS), Cloud Functions (GCP), Azure Functions
  • Trigger par événements (HTTP, queue, schedule, S3 upload)
  • Pay-per-execution, scaling automatique
  • Pas de gestion de serveurs

Event-driven architecture ​

  • Producteurs et consommateurs découplés
  • Message brokers (Kafka, RabbitMQ, AWS SQS/SNS, Google Pub/Sub)
  • Processing asynchrone
  • Résilience et scalabilité

CQRS + Event Sourcing (avancé) ​

  • Séparation Command (écriture) / Query (lecture)
  • Event store comme source de vérité
  • Projections pour les lectures
  • Complexe mais puissant pour certains domaines

Refactor / Re-architect : Cloud-native (suite) ​

Processus de refactoring ​

1. Assessment et design ​

  • Analyser le monolithe existant
  • Identifier les bounded contexts (DDD)
  • Définir les microservices
  • Concevoir les APIs et contrats
  • Choisir les patterns (sync/async, data management)

2. Strangler pattern ​

  • Implémenter les nouveaux services progressivement
  • Router une partie du trafic vers le nouveau
  • Le nouveau "étrangle" progressivement l'ancien
  • Décommissionner l'ancien par morceaux

3. Refactoring incrémental ​

  • Extraire un service à la fois
  • Commencer par les moins couplés
  • Tests intensifs (unit, integration, e2e)
  • Feature flags pour activer/désactiver

4. Data migration ​

  • Pas de base partagée : chaque microservice son datastore
  • Stratégie de migration des données
  • Synchronisation temporaire (dual writes, CDC - Change Data Capture)
  • Eventual consistency à gérer

Avantages ​

  • ✅ Scalabilité fine : scale par service selon la charge
  • ✅ Résilience : isolation des pannes
  • ✅ Déploiement indépendant : CI/CD par service, release rapide
  • ✅ Innovation : technologies différentes par service (polyglot)
  • ✅ Équipes autonomes : ownership par équipe/service
  • ✅ Optimisation cloud : tire pleinement parti des capacités

Inconvénients ​

  • ❌ Complexité : distribution, réseau, observabilité
  • ❌ Coût élevé : refactoring complet, temps de dev long
  • ❌ Compétences : nécessite expertise cloud-native
  • ❌ Risques : réécriture = bugs potentiels
  • ❌ Data consistency : eventual consistency difficile à gérer
  • ❌ Debugging : tracing distribué complexe

Quand l'utiliser ​

  • Applications critiques à fort trafic variable
  • Besoin d'innovation et d'agilité maximales
  • Équipes matures DevOps/SRE
  • Budget et temps disponibles (6-24 mois selon taille)
  • Application destinée à vivre longtemps
  • Business case solide (ROI à long terme)

Anti-patterns à éviter ​

  • Distributed monolith : microservices trop couplés (pire que monolithe)
  • Nanoservices : trop de granularité (overhead)
  • Shared database : défait l'isolation des microservices
  • Synchronous coupling : chaînes d'appels sync fragiles

Exemple ​

Application monolithe e-commerce refactoré :

  • Service Catalog : gestion produits (PostgreSQL)
  • Service Cart : panier (Redis)
  • Service Order : commandes (PostgreSQL + event sourcing)
  • Service Payment : paiements (intégration Stripe)
  • Service Notification : emails/SMS (serverless)
  • Service Recommendation : ML (Python + BigQuery)
  • API Gateway : routage et authentification
  • Event Bus : Kafka pour événements inter-services

Architecture hexagonale, DDD, CQRS sur certains services.

Replace : SaaS / COTS ​

Principe ​

Remplacer une application custom par une solution SaaS ou COTS (Commercial Off-The-Shelf).

Exemples classiques ​

  • Email : Exchange on-premise → Office 365 / Google Workspace
  • CRM : développement maison → Salesforce / HubSpot
  • Comptabilité : ERP custom → SAP, Oracle, Sage
  • Collaboration : SharePoint on-premise → Microsoft 365 / Notion / Confluence Cloud
  • RH : SIRH custom → Workday / SAP SuccessFactors
  • Service Desk : custom → Jira Service Management / ServiceNow
  • Monitoring : Nagios → Datadog / New Relic

Processus ​

  1. Évaluation des besoins : fonctionnalités requises
  2. Sélection solution : RFP, POC, comparaison vendors
  3. Gap analysis : fonctionnalités manquantes vs besoins
  4. Migration données : export ancien système, import nouveau
  5. Configuration : paramétrage du SaaS
  6. Customisation : workflows, intégrations (APIs)
  7. Formation utilisateurs
  8. Cutover et go-live

Avantages ​

  • ✅ Zero maintenance : tout géré par le vendor
  • ✅ Innovation continue : mises à jour automatiques
  • ✅ Scalabilité : incluse dans le service
  • ✅ Coût prévisible : abonnement par user/mois
  • ✅ Time-to-value : opérationnel rapidement
  • ✅ Best practices : processus standards éprouvés

Inconvénients ​

  • ❌ Personnalisation limitée : contraintes du produit
  • ❌ Lock-in SaaS : dépendance au vendor
  • ❌ Coûts récurrents : OPEX perpétuel
  • ❌ Données externalisées : conformité à vérifier
  • ❌ Intégration : APIs parfois limitées
  • ❌ Changement processus : adaptation des utilisateurs nécessaire

Quand l'utiliser ​

  • Fonctionnalités non différenciantes (commodité)
  • Besoin standard bien couvert par le marché
  • Pas de valeur ajoutée à développer soi-même
  • Équipe IT limitée
  • Focus sur le core business

Change management ​

L'adoption de SaaS implique souvent un changement culturel et processus :

  • Formation des utilisateurs
  • Adaptation des workflows
  • Gestion de la résistance
  • Communication sur les bénéfices

Exemple ​

Un outil de ticketing développé en interne. Il fonctionne mais monopolise 1 dev pour la maintenance. Migration vers Zendesk ou Jira Service Management :

  • Coût : 50€/user/mois
  • Gain : libère le dev, fonctionnalités modernes (mobile, analytics, chatbot)
  • Perte : certaines customisations spécifiques disparaissent
  • ROI : positif si >10 users

Gestion de la transition ​

Principes clés ​

Minimiser les risques ​

  • Migration progressive (pas de big bang)
  • Tests rigoureux à chaque étape
  • Rollback plan systématique
  • Environnements de staging/pre-prod

Assurer la continuité ​

  • Fenêtres de maintenance planifiées
  • Communication aux utilisateurs
  • Monitoring 24/7 durant la transition
  • Équipe on-call durant cutover

Gérer les données ​

  • Backup complet avant migration
  • Validation d'intégrité post-migration
  • Stratégie de synchronisation (si coexistence)
  • Archivage de l'ancien système

Patterns de migration ​

Blue/Green deployment ​

  • Environnement "Blue" (actuel) et "Green" (nouveau)
  • Migration complète sur Green
  • Tests sur Green
  • Bascule DNS/LB de Blue vers Green
  • Rollback immédiat possible (re-bascule sur Blue)
  • Une fois validé, Blue peut être décommissionné

Canary deployment ​

  • Déployer le nouveau sur une petite partie du trafic (5-10%)
  • Observer métriques (erreurs, latence, business KPIs)
  • Si OK, augmenter progressivement (20%, 50%, 100%)
  • Rollback immédiat en cas de problème

Feature flags / Toggle ​

  • Nouveau code déployé mais inactif
  • Activation progressive par feature flag
  • Permet A/B testing
  • Rollback = désactiver le flag (pas de redéploiement)

Parallel run ​

  • Ancien et nouveau systèmes fonctionnent en parallèle
  • Même données envoyées aux deux
  • Comparaison des résultats
  • Bascule une fois confiance établie
  • Coûteux (double infrastructure) mais très sécurisé

Phases de migration typiques ​

Phase 1 : Préparation (1-3 mois) ​

  • Assessment et inventaire
  • Choix de stratégie par application
  • Design architecture cible
  • Setup environnements cloud (réseau, IAM, outils)
  • Formation équipe

Phase 2 : Pilot / POC (1-2 mois) ​

  • Migrer 1-2 applications non-critiques
  • Valider les process
  • Apprendre et ajuster
  • Démontrer la faisabilité

Phase 3 : Vagues de migration (6-24 mois) ​

  • Migrer par vagues (par criticité, complexité)
  • Vague 1 : applications simples (quick wins)
  • Vague 2 : applications métier
  • Vague 3 : applications critiques/complexes
  • Pause entre vagues pour consolider

Phase 4 : Optimisation (continue) ​

  • Right-sizing
  • Refactoring progressif
  • Optimisation coûts
  • Amélioration continue

Phase 5 : Décommissionnement (final) ​

  • Arrêt ancien système
  • Archivage données
  • Libération infrastructure on-premise (si applicable)

Cohabitation ancien/nouveau SI ​

Durant la transition (qui peut durer des années en hybride), l'ancien et le nouveau coexistent.

Défis de la cohabitation ​

Intégration ​

  • Ancien système on-premise, nouveau dans le cloud
  • Communication réseau (VPN, Direct Connect)
  • Latence à gérer
  • Sécurité des flux

Données partagées ​

  • Synchronisation entre environnements
  • Source de vérité unique ou distribuée ?
  • Eventual consistency
  • Outils : ETL, CDC (Change Data Capture), event streaming (Kafka)

Identité et accès ​

  • SSO unifié (SAML, OIDC)
  • Fédération d'identités
  • Azure AD, Okta, Ping Identity

Monitoring unifié ​

  • Vue d'ensemble ancien + nouveau
  • Corrélation des logs et métriques
  • Alerting cohérent
  • SIEM central

Patterns d'intégration ​

API Gateway / Façade ​

  • Couche d'abstraction devant ancien + nouveau
  • Routage intelligent selon la fonctionnalité
  • Permet migration transparente pour les clients

Event-driven integration ​

  • Ancien et nouveau publient des événements
  • Event bus central (Kafka, AWS EventBridge)
  • Découplage temporel et spatial
  • Rejouabilité (replay events)

Database replication ​

  • Réplication bidirectionnelle (si besoin)
  • Synchronisation quasi temps réel
  • Tools : AWS DMS, GoldenGate, Debezium (CDC)

ETL / Batch sync ​

  • Synchronisation périodique (nuit)
  • Pour données moins critiques
  • Plus simple mais moins réactif

Example architecture hybride transitoire ​

[Ancien SI on-premise]
    |
    | VPN / Direct Connect
    |
[Intégration Layer]
    | 
    +-- API Gateway (routage ancien/nouveau)
    +-- Event Bus (Kafka)
    +-- Data Sync (CDC / ETL)
    |
[Nouveau SI cloud]

Utilisateurs → API Gateway → route vers ancien OU nouveau selon la fonctionnalité migrée

Gouvernance durant la transition ​

Change management ​

  • Processus de validation des changements
  • Éviter les modifications sur système en migration
  • Freeze code sur ancien SI (sauf bugs critiques)

Documentation ​

  • Cartographie à jour (quoi où)
  • Runbooks ancien + nouveau
  • Procédures de bascule/rollback

Communication ​

  • Transparence avec les utilisateurs
  • Planning de migration communiqué
  • Downtime anticipé et annoncé

Risques et mitigation ​

Risque : Interruption de service ​

  • Mitigation : tests exhaustifs, rollback plan, fenêtres de maintenance

Risque : Perte de données ​

  • Mitigation : backups, validation d'intégrité, dry-run

Risque : Dégradation performance ​

  • Mitigation : load testing, monitoring, canary deployment

Risque : Explosion des coûts cloud ​

  • Mitigation : FinOps, budgets/alertes, tagging rigoureux

Risque : Compétences insuffisantes ​

  • Mitigation : formation anticipée, accompagnement externe, documentation

Risque : Sécurité compromise ​

  • Mitigation : security by design, audits, pentest

KPIs de migration ​

Pour piloter la migration, définir des KPIs :

  • Avancement : % applications migrées
  • Performance : latence, throughput vs baseline
  • Disponibilité : uptime durant migration
  • Coûts : budget vs réel
  • Qualité : nombre d'incidents, bugs post-migration
  • Adoption : satisfaction utilisateurs

Lessons learned et retrospectives ​

Après chaque vague :

  • Rétrospective équipe (ce qui a marché, ce qui a échoué)
  • Ajustement du plan
  • Documentation des learnings
  • Partage avec les autres équipes