VM Apps vers All Apps : l’étude décisionnelle avant de migrer

L’upgrade vers VCF Automation 9.1 vient de se terminer. Les déploiements historiques sont encore là, les équipes parlent déjà d’All Apps, et une question apparemment simple arrive au comité d’architecture : « comment convertir notre organisation VM Apps ? » C’est précisément la mauvaise question. La documentation publique décrit une coexistence puis une migration, pas une transformation magique de l’organisation existante.

Cet article fournit un cadre de décision pour un environnement brownfield issu d’Aria Automation 8.18.1 ou ultérieur. Il sépare la topologie de transition, la stratégie de chaque service et les conditions de retrait du legacy. Le fil rouge est WebShop, une application trois tiers encore exploitée dans acme-vmapps-legacy et destinée à être reconstruite dans une organisation All Apps distincte.

TL;DR

• L’upgrade préserve le modèle historique dans VM Apps ; il ne transforme pas ses objets en objets All Apps. La cible est une nouvelle organisation avec ses propres identités, projets, quotas, Namespaces, VPC et identifiants.
• Le coût réel ne réside pas dans la création de l’organisation cible, mais dans la reconstruction du contrat de service : réseau, données, politiques, extensions, observabilité et dépendances externes.
• Commence par une décision écrite sur trois axes — topologie, stratégie applicative, sortie — puis choisis un pilote stateless dont le rollback est une bascule de trafic, pas une suppression d’organisation.

Remplacer la question de conversion par trois décisions

L’absence de procédure publique de conversion en place ne prouve pas qu’une opération soit techniquement impossible dans tous les cas. Elle impose une règle d’ingénierie plus sobre : ne jamais faire dépendre le programme d’un mécanisme non documenté. Si un client estime qu’une conversion existe pour son build et sa topologie, il lui faut une confirmation écrite de GSS, avec le périmètre exact des objets et du support.

Le dossier de décision doit répondre séparément à trois questions. Premièrement, quelle infrastructure accueillera All Apps pendant la coexistence ? Deuxièmement, que devient chaque service applicatif ? Troisièmement, quelles preuves autoriseront le gel, la désactivation puis éventuellement la suppression de VM Apps ? Mélanger ces réponses produit des raccourcis dangereux, comme considérer qu’un cluster séparé résout l’isolation du plan de management ou qu’un export YAML déplace l’état d’un déploiement.

decision_record:
  evidence_status: reconstructed_design
  transition_topology: separate_clusters_shared_vcenter_nsx
  application_strategy:
    webshop: rebuild_in_all_apps
    legacy_batch: retire_after_usage_review
  retirement_condition:
    - no_new_vm_apps_requests
    - no_unaccepted_external_dependency
    - rollback_window_closed_by_owner
  in_place_conversion: excluded_without_written_gss_confirmation

Ce YAML n’est pas une configuration VCF Automation. C’est un contrat d’architecture versionnable : chaque valeur doit être approuvée par les responsables plateforme, réseau, sécurité, exploitation et application.

Choisir une topologie de transition, pas seulement une cible

La documentation Broadcom 9.1 décrit un modèle bimodal dans lequel VM Apps et All Apps peuvent partager vCenter et NSX sous les conditions de Mixed Tenancy. La séquence compte : VM Apps doit être configurée avant la Region All Apps sur la paire partagée. La séquence inverse est documentée comme non supportée. Le partage est donc un pont encadré, pas une propriété à supposer après coup.

Option	Quand elle a du sens	Coût ou limite structurante
VM Apps seule	report court avec date de réexamen	aucune adoption All Apps, dette prolongée
même cluster partagé	pilote peu critique, capacité disponible	contention, blast radius commun, isolation non stricte
clusters séparés, vCenter/NSX communs	transition d’entreprise avec isolation de capacité	visibilité et API du plan de management restent partagées
infrastructure All Apps dédiée	production réglementée ou frontière de sécurité forte	capacité, réseau et exploitation temporairement dupliqués
VCF Instance ou fleet dédiée	souveraineté ou séparation maximale	coût et complexité opérationnelle les plus élevés

Un test de sécurité est indispensable avant de retenir Mixed Tenancy. Broadcom prévient qu’une visibilité en lecture de ressources All Apps peut exister depuis VM Apps et que le mode n’est pas adapté à une production exigeant une multi-tenancy stricte. Si ce comportement est incompatible avec le modèle de menace, la discussion s’arrête : la cible doit être dédiée, même si le budget aurait préféré partager.

La capacité doit être testée avec la même franchise. Deux clusters sous un même vCenter et un même NSX réduisent la contention compute, mais pas la pression sur les API et le plan de management. Il faut mesurer la baseline, définir des seuils locaux et réserver les fenêtres de migration. Aucun chiffre générique ne remplace ces observations.

Migrer un service, pas une VM isolée

Pour WebShop, l’unité utile comprend les trois tiers, les flux entre eux, la résolution DNS, le load balancer, les comptes d’ordinateur, les réservations IPAM, les CI de CMDB, la sauvegarde, le monitoring et les données. Déplacer une VM sans ce graphe peut produire un objet vert dans l’interface et un service inutilisable pour ses consommateurs.

Chaque service reçoit une stratégie explicite :

Stratégie	Décision	Exemple WebShop
conserver	le risque du changement dépasse le bénéfice immédiat	base historique conservée pendant la première vague
retirer	le service n’a plus d’usage démontré	ancien serveur batch après archive et accord du propriétaire
reconstruire	même fonction, nouveau contrat All Apps	tiers Web et App redéployés dans le Namespace cible
reconditionner	une image ou un OVF/OVA sert de point de départ	appliance difficile à automatiser, sans prétendre transférer son historique
moderniser	le runtime ou le service change également	base vers DSM dans une vague ultérieure

La recommandation du fil rouge est de reconstruire avant de moderniser. Changer simultanément de tenancy, de réseau, de runtime et de moteur de données augmente le nombre d’hypothèses à diagnostiquer pendant la fenêtre de retour. La modernisation reste un objectif valable, mais elle mérite sa propre vague une fois le service reproductible dans All Apps.

Mesurer la portabilité sur quatre dimensions

« On peut exporter » est une phrase insuffisante. Pour chaque objet, l’analyse doit distinguer : l’export depuis la source, l’import accepté par la cible, la compatibilité sémantique et le transfert de l’état runtime. Un Custom Form exportable peut encore référencer des IDs, actions externes et valeurs dynamiques qui n’existent pas dans la nouvelle organisation. Un package Orchestrator importable ne transporte pas automatiquement endpoints, certificats, credentials et exécutions passées.

Objet	Traitement prudent par défaut
projets, groupes et rôles	recréer, remapper et tester avec des non-admins
Cloud Templates contenant Cloud.*	reconstruire selon le modèle de ressources All Apps
Custom Forms	exporter comme aide, rebrancher toutes les dépendances, retester
subscriptions et politiques	recréer avec les topics, payloads, portées et rôles observés sur la cible
déploiements actifs et historique	conserver puis drainer, ou redéployer ; aucun transfert générique documenté
secrets, tokens et credentials	recréer et tourner, jamais copier depuis un export

Le point clé est sémantique. formatVersion: 1 ne suffit pas à identifier un Blueprint legacy ; ce sont les types Cloud.*, les profils, les actions et les dépendances qui déterminent la réécriture. De même, partager vCenter et NSX évite de déplacer certains plans d’infrastructure, mais ne convertit ni un segment legacy en VPC ni une cloud zone en Region Quota.

Concevoir le rollback avant le pilote

Le rollback du programme vit au niveau du service. Avant le cutover, la cible peut être corrigée ou supprimée sans toucher à WebShop legacy. Après la bascule mais avant toute écriture nouvelle, le trafic peut revenir vers la source. Après des écritures sur la cible, le retour exige un gel, une réplication inverse ou une restauration déjà répétée.

Cette distinction détermine le pilote. Une application stateless, de faible criticité, avec peu d’extensions et un mécanisme DNS ou load balancer maîtrisé expose les problèmes de tenancy sans ajouter immédiatement une migration de données irréversible. Le pilote doit inclure le cycle complet : provisionnement, contrôle des rôles, Day‑2, panne, retour de trafic et nettoyage des objets externes.

Le dossier à apporter au comité de décision

La réunion utile ne se termine pas par « All Apps est la cible ». Elle produit un schéma source/cible, une décision de topologie, le résultat attendu du test de visibilité, une hypothèse de capacité, une matrice des services, un propriétaire par dépendance externe et des conditions mesurables de sortie. Elle attribue également une autorité go/no-go et une autorité de rollback.

Pour WebShop, une première proposition raisonnable est de conserver la base dans VM Apps pendant que les tiers Web et App sont reconstruits dans All Apps, puis de migrer les données dans une vague distincte avec chemin inverse testé. Ce choix n’est pas une vérité produit : c’est une hypothèse de design qui réduit le nombre de changements simultanés.

Les coûts cachés doivent figurer dans la même décision : capacité doublée pendant le blue-green, Supervisor et réseau VPC, stockage de Content Library, deux catalogues, nouvelles règles de sécurité, adaptation des workflows et rapports, tests de sauvegarde, formation et conservation de deux jeux d’identifiants. Sans cette ligne budgétaire, la coexistence « temporaire » tend à devenir permanente.

Pièges & points de vigilance

• Ne crée pas All Apps sur une paire partagée avant d’avoir vérifié l’ordre Mixed Tenancy applicable.
• Ne laisse pas VM Apps et All Apps écrire simultanément dans DNS, IPAM, AD, CMDB ou le load balancer pour le même objet.
• Ne publie aucun RPO, RTO, coût ou délai tant qu’il n’a pas été mesuré dans le contexte client.
• Ne supprime pas VM Apps pour « libérer » l’infrastructure avant la fermeture formelle de la fenêtre de retour.

Sources officielles Broadcom

• Bimodal Consumption Design for VM Apps and All Apps Workloads
• Managing Regions in VCF Automation
• Create a VCF Automation Organization for All Applications
• Tenancy Deployment Models with VMware Cloud Foundation
• KB 443541 — Unable to Add a Cloud Account on Shared Infrastructure
• KB 444058 — Configuring a Shared vCenter and NSX Manager

Conclusion

Le parcours soutenable n’est ni un big bang ni une promesse de conversion universelle. Il stabilise VM Apps, construit une cible distincte, migre par services, prouve le rollback puis retire progressivement le legacy. L’article suivant établit la baseline post-upgrade de l’organisation VM Apps avant toute construction All Apps.