Skip to content
Edouard Topin
vcf-9 architecture broadcom private-cloud vmware

La nouvelle architecture VCF 9 expliquée aux architectes

VCF 9 n'est pas un upgrade mineur : c'est une refonte complète du modèle opérationnel. Ce qu'un architecte cloud doit comprendre avant tout projet d'adoption.

Edouard Topin

2 min read 2 min de lecture
VMware Cloud Foundation 9 — architecture overview

Si tu ouvres la console d’un déploiement VCF 9 avec tes réflexes VCF 5.x, tu es perdu en trente secondes. SDDC Manager n’est plus le point d’entrée, les onze licences sont devenues deux, et plusieurs features considérées acquises ont disparu. Ce n’est pas un upgrade : c’est un reset architectural.

Features suppriméesLicensing simplifiéModèle opérationnel refondu

La rupture en trois points

Broadcom a appliqué sa méthode habituelle au portefeuille VMware : simplification radicale, consolidation des SKU, élagage des features héritées. VCF 9 est la traduction visible côté private cloud — une plateforme unifiée pour VM, Kubernetes et workloads IA, avec un modèle opérationnel cohérent.

La contrepartie est une rupture assumée avec plusieurs design patterns historiques :

  • Hiérarchie refondée — Fleet / Instance / Private Cloud remplacent les workload domains
  • Centre de gravité déplacé — VCF Operations orchestre, SDDC Manager exécute
  • Features supprimées — vVols, SIOC, ELM, Host Profiles, IWA : documenter avant migration

La nouvelle hiérarchie à trois niveaux

Hiérarchie Fleet / Instance / Private Cloud en VCF 9
NiveauRôleÉquivalent VCF 5.x
Private CloudUnité logique de consommation
FleetGouvernance, licensing, compliance, patchingDomaine de gestion
InstanceDéploiement physique (clusters + vCenter)Workload Domain

La première question en VCF 9 n’est plus « combien de workload domains » mais « combien de Fleets, selon quelle frontière » — géographique, réglementaire ou métier.

VCF Operations : le nouveau centre de gravité

Déplacement du centre de gravité : SDDC Manager vers VCF Operations entre VCF 5.x et VCF 9

VCF Operations orchestre désormais le cycle de vie complet de la flotte :

  • Gestion des licences et soumission d’usage
  • Renouvellement des certificats et identité
  • Patch et lifecycle à l’échelle de la flotte
  • Compliance continue, monitoring, analyse de logs
  • Cost & capacity management natif (showback/chargeback, forecasting)

SDDC Manager conserve un rôle d’exécuteur — plus de chef d’orchestre. Pour les organisations qui s’appuyaient sur Aria Operations + extensions maison, la bascule représente à la fois une simplification et une perte de customisation.

VCF Automation : la couche self-service unifiée

Le remplaçant d’Aria Automation, repensé pour s’intégrer au modèle Fleet. Deux portails structurent l’expérience :

Provider Portal

Administrateur plateforme : organisations, allocations capacité, politiques globales, gestion multi-tenant.

Organization Portal

Consommateur : projets, blueprints, catalog items, déploiements VM, VKS, VPC, volumes, secrets.

Le catalog couvre VM, Kubernetes (VKS), réseaux VPC, volumes persistants, secrets, databases (DSM), registres Harbor. Points d’entrée : UI, CLI, API REST, et une API Kubernetes IaaS qui expose les ressources via kubectl — clé pour les équipes GitOps.

VCF Automation est la couche obligatoire pour tout déploiement multi-tenant, et fortement recommandée dès qu’on veut industrialiser.

Virtual Private Cloud : networking accessible

Architecture VPC au-dessus de NSX dans VCF 9
Abstraction self-service au-dessus de NSX. Subnets, routing, security groups exposés avec un modèle proche d’AWS/Azure VPC. L’administrateur vSphere crée des réseaux isolés sans écrire une seule policy NSX. Création visuelle dans vCenter, policies appliquées par défaut.
Abaisse drastiquement la barrière réseau. Un projet qui demandait un architecte réseau dédié peut être cadré par un architecte généraliste. Rend VCF Automation réellement utilisable en multi-tenant sans expertise NSX côté tenant.
VPC par défaut pour 80 % des cas : isolation tenant, segmentation applicative, exposition via load balancer géré. NSX direct pour les 20 % restants : multicast, traffic mirroring fin, architectures N-tiers complexes, intégrations BGP avancées. Sous le capot, le VPC tourne toujours sur NSX — c’est une couche de contrôle simplifiée, pas un nouveau data plane.

Identity Broker : authentification unifiée au niveau Fleet

VCF 9 introduit un Identity Broker unifié, supportant SAML et OIDC, appliqué globalement à l’exception d’ESX et SDDC Manager qui conservent leur configuration locale. Source de vérité unique pour l’audit et la conformité.

La contrepartie : suppression d’Integrated Windows Authentication (IWA). Les environnements qui reposaient sur l’IWA doivent migrer vers LDAPS ou une fédération d’identité externe.

Ce qui a disparu dans VCF 9

Ne supposer jamais qu’une feature VCF 5.x est présente en VCF 9 sans vérification explicite dans les release notes 9.0.

Ce qui est arrivé : les nouveautés qui comptent

FIPS 140-3 par défaut

Non désactivable. Tous composants (vCenter, ESX, NSX) en mode FIPS. À valider pour les intégrations tierces.

Memory tiering NVMe

Flash NVMe en 2e tier. Idéal pour JVM-heavy, analytics, HFT. Tier plus lent — pas de la RAM gratuite.

vMotion for AI

Migration live des workloads GPU-heavy avec downtime quasi nul. Changement significatif pour l’IA sur VCF.

Déduplication globale

Scope cluster entier vs disk-level. Gains capacité réels sans impact performance post-process traditionnel.

vTopology automatique

Détection et correction des vCPU/vNUMA mal configurés. Fin d’une source récurrente de tickets support.

1 GbE management (9.0.2)

Officiellement supporté pour les workflows d’import. Débloque les sites brownfield sans budget 10 GbE.

7 décisions de design à trancher avant d’adopter

1. Combien de Fleets ?

Géographique, réglementaire ou métier — un axe, assumé. Engage la gouvernance pour plusieurs années.

2. Connected ou air-gapped ?

Impacte le licensing (soumission auto vs manuelle), le patch management et l’observabilité.

3. VPC ou NSX direct ?

VPC par défaut, NSX direct pour les exceptions. Documenter les cas qui basculent en NSX direct.

4. VCF Automation dès J1 ?

Oui si multi-tenant ou besoin IaC fort. Après si démarrage single-tenant avec équipe non-automation.

5. Greenfield ou brownfield ?

9.0.2 a amélioré les workflows d’import y compris sur réseau 1 GbE. Option brownfield réellement viable.

6. Convergence ou rebuild ?

Chemin officiel depuis vSphere 8. Évaluer selon l’âge et la dette technique de l’environnement existant.

7. Identity Federation : quel IdP ?

Entra ID, Okta, Ping — décision avec l’équipe IAM, pas en silo plateforme.

Chacune mérite un chapitre dédié dans le document d’architecture. Sans arbitrage formel, c’est une installation, pas un projet d’architecture.

Conclusion : trois choses à retenir

Nouvelle hiérarchie

Fleet / Instance / Private Cloud — les workload domains VCF 5.x ne sont plus le bon cadre mental.

Hubs recentrés

VCF Operations orchestre, VCF Automation expose le self-service. SDDC Manager n’est plus le point d’entrée. Le RACI doit le refléter.

Suppressions non négligeables

vVols, SIOC, ELM, Host Profiles, IWA — cataloguer tôt pour éviter les mauvaises surprises en migration.

Pour aller plus loin : les Release Notes VCF 9.0 de Broadcom, le guide Paths to Adoption sur le VCF Blog, et côté communauté les deep-dives de William Lam et vrealize.it.

Back to Blog
Share:

Follow along

Stay in the loop — new articles, thoughts, and updates.