La fin de l'ère Azure VMware Solution : Microsoft cède à la pression de Broadcom

Microsoft a officiellement annoncé l'arrêt de la vente de nouvelles licences pour Azure VMware Solution (AVS) avec les licences VMware incluses. Cette décision marque la capitulation de Redmond face aux exigences agressives de Broadcom, qui a acquis VMware et imposé un modèle commercial plus strict. Pour les consultants IT et les architectes cloud, cette bascule impose une réévaluation immédiate des stratégies de migration des environnements vSphere et ESXi hébergés sur Azure.

En bref

• Fin des nouvelles souscriptions : Microsoft ne vend plus de nouveaux forfaits AVS incluant les licences VMware à partir de la date d'annonce.
• Contrats existants : Les clients actuels peuvent généralement maintenir leurs licences jusqu'à l'échéance de leur contrat, mais aucune extension ni nouveau déploiement n'est autorisé.
• Impact direct : Les entreprises dépendant d'AVS pour virtualiser leurs workloads critiques doivent planifier une migration vers des alternatives (Azure IaaS, VMware Cloud on AWS, ou on-premises).
• Coût de la migration : La transition vers une solution purement Azure (Hyper-V) ou vers un autre hyperviseur engendre des coûts de refactoring, de requalification et de formation.
• Signal du marché : Cette décision illustre la fin de l'interopérabilité "sans friction" entre les grands cloud providers et les éditeurs de logiciels virtuels post-fusion avec Broadcom.

Le contexte : une bataille commerciale inévitable

Pendant des années, Azure VMware Solution a représenté une niche stratégique pour Microsoft. En permettant aux entreprises d'exploiter leur expertise VMware dans le cloud Azure, Redmond attirait une clientèle enterprise fidèle, souvent réticente à l'idée de migrer ses workloads vers l'hyperviseur propriétaire Hyper-V. C'était un pont parfait entre l'inertie de l'existant et la modernisation cloud.

Tout a changé avec l'acquisition de VMware par Broadcom. Le nouveau propriétaire a réorienté radicalement la stratégie de pricing, passant d'un modèle par socket à un modèle par vCPU, et imposant des restrictions sur la co-habitation avec d'autres clouds publics. Broadcom a clairement signalé à Microsoft qu'il refusait que ses licences soient utilisées comme un simple "produit d'appel" ou un moyen de fidélisation pour Azure, sans que les revenus de la licence ne profitent directement à l'éditeur.

Après des mois de négociations et de résistances, Microsoft a fini par céder. L'annonce de la cessation des ventes de nouvelles licences incluses n'est pas une erreur technique, mais une décision business pure. Microsoft préfère sacrifier cette offre hybride plutôt que de s'engager dans une guerre tarifaire qu'il ne peut pas gagner face à Broadcom, qui contrôle désormais la chaîne de valeur logicielle.

Conséquences techniques pour les environnements AVS

Pour un consultant système, comprendre l'impact technique de cette décision est crucial. Azure VMware Solution n'est pas un simple PaaS ; c'est une infrastructure de virtualisation complète basée sur vSphere.

L'état des lieux actuel

Les environnements AVS actuels reposent sur :

1. vCenter Server : Hébergé dans le cloud Azure, géré par Microsoft.
2. ESXi Hosts : Les serveurs physiques sous-jacents sont gérés par l'infrastructure Azure, mais exposés via l'API vSphere.
3. Réseau : Intégration via Azure VNet, permettant la communication directe entre les VMs VMware et les ressources Azure natives.

Avec la fin des nouvelles licences, toute tentative de création d'un nouvel environnement AVS, ou d'ajout de capacité (scale-out) via l'interface Azure Portal ou la CLI, sera bloquée si la souscription requiert l'achat de nouvelles licences VMware.

Les limites des contrats existants

Il est impératif de vérifier la clause de "True-up" ou d'extension de vos contrats actuels.

• Contrats annuels : Vous pouvez généralement utiliser vos licences jusqu'à la fin de la période payée.
• Paiement à l'usage (Pay-as-you-go) : C'est ici que le risque est le plus élevé. Microsoft a indiqué que les nouveaux déploiements seront interdits. Les extensions de capacité pour les environnements existants pourraient être limitées ou suspendues selon les conditions contractuelles régionales.
• Support : Le support technique pour les environnements AVS existants restera disponible, mais il est probable que Microsoft réduise progressivement les efforts de développement de nouvelles fonctionnalités spécifiques à AVS, se concentrant sur la stabilité et la maintenance corrective.

Stratégies de migration : les options concrètes

Face à cette impasse, les organisations ont trois voies principales. Chaque option implique des compromis différents en termes de coût, de complexité et de performance.

Option 1 : Migration vers Azure IaaS (Hyper-V)

C'est la voie la plus "native" pour Microsoft, mais la plus douloureuse pour les équipes VMware.

• Avantages : Intégration native avec Azure AD, Azure Monitor, et les services de sécurité Azure. Coûts prévisibles, pas de surcoût de licence hyperviseur (le coût est inclus dans l'instance).
• Inconvénients :
  • Perte de l'écosystème vSphere : Fin de vMotion, DRS, et de l'interface vCenter familière.
  • Refactoring applicatif : Certaines applications dépendantes de fonctionnalités spécifiques vSphere ou de plugins VMware Tools devront être requalifiées.
  • Compétences : Les équipes doivent se former à l'administration des machines virtuelles Azure et à la gestion des disques managés.

Commande d'exemple pour la création d'une VM Azure équivalente :

# Création d'une VM Linux sur Azure (équivalent d'une VM ESXi)
az vm create \
  --resource-group myResourceGroup \
  --name myVM \
  --image UbuntuLTS \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys

# Ajout d'un disque managé supplémentaire (équivalent d'une datastore)
az disk create \
  --resource-group myResourceGroup \
  --name myDisk \
  --size-gb 200 \
  --sku StandardSSD_LRS

az vm disk attach \
  --resource-group myResourceGroup \
  --vm-name myVM \
  --name myDisk \
  --caching None

Option 2 : Migration vers VMware Cloud on AWS (VMC)

Si la dépendance à l'écosystème VMware est trop forte pour être abandonnée, VMC sur AWS est l'alternative la plus proche de l'expérience AVS.

• Avantages : Même stack logicielle (vSphere, NSX, vSAN). Migration "lift and shift" possible via les outils de migration VMware. Pas de changement de compétences pour les admins.
• Inconvénients :
  • Coût : VMC est souvent plus cher qu'AVS en raison des frais de connectivité AWS et des licences VMware.
  • Connectivité : La connexion entre Azure et VMC (via ExpressRoute et Direct Connect) nécessite une architecture réseau complexe et coûteuse (SD-WAN ou interconnects privés).
  • Latence : Les workloads inter-applicatifs entre Azure et VMC souffriront de la latence inter-cloud.

Option 3 : Retour On-Premises ou Edge

Pour les entreprises avec une forte empreinte physique, il peut être plus économique de rapatrier les workloads critiques sur une infrastructure locale moderne (Proxmox, KVM, ou vSphere on-premises) plutôt que de payer le premium cloud.

• Avantages : Contrôle total du matériel, latence minimale, coûts de licence VMware on-premises souvent négociables avec Broadcom.
• Inconvénients : Investissement initial élevé (CAPEX), gestion de la maintenance matérielle, complexité de la réversibilité (il est difficile de repartir vers le cloud ensuite).

Impact sur l'architecture réseau et la sécurité

La suppression d'AVS affecte directement la conception des réseaux hybrides.

1. Interconnexions : Les entreprises qui utilisaient AVS pour bénéficier d'une connectivité privée directe entre leurs datacenters on-premises et le cloud Azure via ExpressRoute vont devoir redessiner cette architecture. Si les VMs migrent vers Azure IaaS, la connectivité ExpressRoute reste pertinente, mais la segmentation des réseaux (VLANs vs VNets) doit être revue.
2. Sécurité : Les politiques de sécurité réseau basées sur NSX (si utilisé avec AVS) devront être remplacées par des Network Security Groups (NSG) Azure et des Azure Firewall. La granularité est différente ; les consultants doivent vérifier que les règles de flux ne sont pas perdues lors de la migration.

Vérification de la connectivité après migration vers Azure IaaS :

# Test de latence et de perte de paquets depuis un VM Azure vers le Datacenter On-Premise
az network private-dns link vnet list --resource-group myResourceGroup

# Utilisation de ping/traceroute depuis la VM Azure
# (À exécuter dans le shell de la VM)
ping -c 4 <ip_datacenter>
traceroute <ip_datacenter>

Bonnes pratiques pour consultants IT

Pour accompagner vos clients dans cette transition, voici une feuille de route actionnable :

1. Audit complet des dépendances :

   • Listez toutes les VMs AVS et leurs dépendances réseau (IPs statiques, DNS, ports ouverts).
   • Identifiez les applications dépendantes de vSphere (ex : monitoring par vRealize, backup par Veeam avec plugins spécifiques).
   • Évaluez la criticité des workloads : les bases de données et les applications transactionnelles sensibles à la latence doivent être traitées en priorité.

2. Planification de la migration par lots :

   • Commencez par les workloads non critiques (dev/test) pour valider le processus de migration.
   • Utilisez des outils comme Azure Migrate pour évaluer la compatibilité des VMs VMware avec Azure IaaS.
   • Prévoyez des fenêtres de maintenance longues, car la migration de VMs de grande taille peut prendre plusieurs heures.

3. Gestion des coûts :

   • Simulez les coûts de la migration vers Azure IaaS avec l'outil Azure Pricing Calculator.
   • Comparez avec les devis de VMware Cloud on AWS.
   • N'oubliez pas les coûts cachés : formation des équipes, refactoring des scripts d'automatisation (PowerShell vs Terraform vs Ansible), et coûts de connectivité réseau.

4. Documentation et formation :

   • Mettez à jour la documentation d'exploitation (Runbooks) pour refléter la nouvelle stack (Hyper-V au lieu d'ESXi).
   • Formez les administrateurs systèmes aux concepts Azure (Resource Groups, VNets, NSGs) si la migration vers IaaS est retenue.

5. Vigilance contractuelle :

   • Relisez les clauses de résiliation et de non-concurrence dans vos contrats avec Microsoft et Broadcom.
   • Vérifiez si vous avez des droits de portabilité de vos configurations vSphere (export des templates, scripts d'automatisation).

Points clés

La fin d'Azure VMware Solution avec licences incluses n'est pas simplement une annonce produit ; c'est un tournant stratégique dans le cloud hybride. Microsoft pousse désormais ses clients vers un écosystème propriétaire (Hyper-V/Azure), tandis que Broadcom monétise son logiciel en limitant sa distribution dans les clouds concurrents.

Pour les consultants IT, le message est clair : l'époque des compromis faciles est révolue. Il faut désormais arbitrer entre la fidélité à l'écosystème VMware (au prix d'une complexité et de coûts accrus) et l'adoption de la stack native Azure (au prix d'un changement de compétences et de processus).

La réussite de cette transition dépendra de la qualité de l'audit initial et de la précision de la planification réseau. Les entreprises qui agiront rapidement, en capitalisant sur leurs contrats AVS existants pour préparer la migration, auront un avantage compétitif majeur sur celles qui attendront la dernière minute. Dans le monde du cloud, l'inertie se paie en coûts et en dette technique.

Source : ChannelNews