Dave Maltz et la pile opérationnelle qui sous-tend le réseau d’Azure

Résumé

• Microsoft présente Dave Maltz comme Technical Fellow et CVP, ainsi que comme le responsable de l’ingénierie d’Azure Networking, une organisation chargée des logiciels et des équipements allant des services réseau destinés aux clients aux commutateurs et aux systèmes optiques.
• Son parcours de recherche suit le même problème d’intégration à travers plusieurs générations: VL2 pour le placement et la conception de la fabrique réseau, SNAP pour le diagnostic, SWAN et OneWAN pour le contrôle des réseaux étendus, CrystalNet pour la sûreté des changements et AccelNet pour le déport programmable vers des SmartNIC.
• Les travaux publiés par Microsoft sur SONiC, les DPU et l’architecture DASH SmartSwitch de 2026 montrent que la question décisive porte de plus en plus sur l’endroit où une fonction réseau doit s’exécuter, plutôt que sur son caractère logiciel ou matériel dans l’absolu.
• Les articles de Microsoft fournissent de solides preuves de première main sur les systèmes et les déploiements déclarés, mais ils ne permettent ni de considérer Maltz comme leur auteur unique, ni de transformer des chiffres de parc datés en décomptes actuels, ni de supposer qu’une infrastructure personnalisée réduit automatiquement le coût total.

Le réseau d’Azure est une organisation avant d’être une topologie

Un réseau de cloud public est souvent représenté sous forme de schéma: des régions reliées par des liaisons longue distance, des centres de données remplis de fabriques leaf-spine, des réseaux virtuels de clients superposés à l’infrastructure physique et des sites périphériques reliés à Internet. Ce schéma décrit des chemins. Il ne décrit pas l’organisation nécessaire pour les rendre fiables alors que des milliers de services, de générations matérielles et de versions logicielles évoluent autour d’eux.

Le profil actuel de Dave Maltz publié par Microsoft rend ce périmètre organisationnel exceptionnellement explicite. Microsoft présente Maltz comme Technical Fellow et CVP, et comme le responsable de l’ingénierie d’Azure Networking. L’organisation développe, déploie et exploite des services de sécurité réseau, le DNS, le contrôle des réseaux logiciels et physiques, le micrologiciel de commutation SONiC, les réseaux de centres de données et les systèmes optiques reliant Azure Public Cloud et Microsoft 365. Son mandat s’étend d’une API client à la fibre physique.

Cette ampleur modifie ce que signifie « exploiter » un réseau cloud. Aucun dirigeant ne configure personnellement chaque commutateur, ne vérifie chaque version DNS ou ne choisit chaque composant optique. L’autorité pertinente réside dans la capacité à aligner des équipes qui, autrement, optimiseraient des couches distinctes. Un service de réseau virtuel peut demander un nouveau mécanisme de politique. Une équipe SmartNIC doit déterminer si ce mécanisme peut entrer dans une chaîne de déport. Le logiciel des commutateurs doit exposer l’état nécessaire. La fabrique doit transporter le trafic en cas de défaillance.

Le plan optique doit fournir la capacité là où le service en aura besoin. Les opérations doivent détecter les défaillances de ces interactions.

Les achats réseau traditionnels séparent nombre de ces décisions. Un fournisseur livre les routeurs, un autre le système optique, un troisième l’équipement de sécurité et un quatrième la plateforme de gestion. L’opérateur les intègre au moyen de contrats et de normes. Un hyperscaler peut internaliser une plus grande part de la pile. Il peut écrire le logiciel de contrôle, influencer le micrologiciel des commutateurs, concevoir le déport côté hôte et planifier le réseau physique comme un seul système d’ingénierie.

L’internalisation crée à la fois un levier et une responsabilité. Une organisation qui maîtrise les interfaces peut optimiser l’ensemble, répondre à de nouvelles charges de travail et réduire sa dépendance au calendrier de publication d’un fournisseur. Elle assume aussi les charges de test, de chaîne d’approvisionnement et de gestion des incidents auparavant supportées par le fournisseur intégré. Les systèmes personnalisés ne deviennent des actifs que si l’opérateur peut les doter en personnel et les renouveler d’une génération matérielle à l’autre.

L’importance de Maltz se situe à cette frontière. Son parcours ne justifie pas un récit héroïque selon lequel une seule personne aurait conçu Azure. Il étaye une autre affirmation: il a consacré une grande partie de sa carrière aux mécanismes permettant de concevoir, mesurer, contrôler et tester de grands réseaux comme des systèmes, et il dirige aujourd’hui l’organisation chargée de mettre ces mécanismes en exploitation.

Cette distinction est importante, car les réseaux à très grande échelle sont collaboratifs par construction. Les articles auxquels Maltz est associé comportent de longues listes d’auteurs. Les systèmes de production dépendent d’équipes d’ingénierie, de fournisseurs de matériel, de communautés open source et de personnels d’exploitation dont le travail n’est pas résumé par un titre de dirigeant. Son rôle se comprend mieux comme celui d’un intégrateur responsable: fixer les priorités, créer des interfaces organisationnelles et assumer la responsabilité des résultats entre les couches.

Les recherches sur le routage dynamique ont fourni un premier modèle de l’information incomplète

Maltz a obtenu un doctorat en informatique à Carnegie Mellon University en 2001 sous la direction de David B. Johnson. Sa thèse portait sur le routage à la demande et le protocole Dynamic Source Routing pour les réseaux sans fil multisauts. Les réseaux mobiles ad hoc sont très éloignés d’un centre de données à très grande échelle par leur matériel et leur économie, mais ils posaient un problème systémique durable: comment les nœuds doivent-ils trouver et conserver des chemins utiles lorsque la topologie change et qu’aucun entité ne dispose d’une vision globale parfaitement à jour?

Cette question revient dans l’ensemble des réseaux cloud. Un contrôleur central peut disposer d’une large visibilité, mais son état est retardé. Un commutateur peut connaître ses files d’attente locales sans connaître les conséquences d’un chemin sur le niveau de service. Un terminal peut observer la latence sans en connaître toutes les causes. La capacité longue distance varie avec les pannes et la maintenance. Toute conception reposant sur une connaissance complète et instantanée finit par se heurter au réseau physique.

Ces premières recherches importent donc moins comme modèle directement applicable que comme apprentissage du contrôle distribué. La découverte des routes, la reprise après défaillance et l’information partielle obligent les concepteurs à préciser ce qui est connu localement, ce qui est déduit et ce qui doit rester sûr lorsque ces hypothèses sont fausses. La même discipline apparaît ensuite dans l’ingénierie du trafic et la vérification des réseaux.

Maltz a rejoint Microsoft Research, où l’accès aux systèmes de production a changé l’échelle des questions. Un réseau de recherche peut être instrumenté autour d’une expérience. Un service commercial produit des schémas de trafic et de défaillance qui n’ont pas été conçus pour faciliter l’analyse. Il contient des choix hérités, du matériel hétérogène et des applications dont les responsables peuvent interpréter différemment un même symptôme.

Cet environnement a favorisé des travaux reliant les mesures à l’architecture. Au lieu de demander uniquement comment rendre un protocole efficace dans un modèle, les chercheurs de Microsoft pouvaient étudier pourquoi un service réel était lent, quelle abstraction réseau limitait le déploiement et comment une modification proposée se comporterait lorsque des milliers de machines ou de liaisons tomberaient en panne selon des combinaisons absentes d’un laboratoire.

Des biographies historiques mentionnent des diplômes antérieurs du Massachusetts Institute of Technology, mais les sources publiques actuelles sont les plus solides concernant le doctorat de Carnegie Mellon et la carrière ultérieure chez Microsoft. Ce détail rappelle utilement la discipline imposée par les sources. Les lacunes biographiques doivent rester telles quelles lorsque les preuves disponibles ne permettent pas de les combler. L’histoire de l’infrastructure est étayée par les systèmes documentés; les informations privées et les détails de CV non corroborés apportent peu.

Une transition professionnelle majeure s’est produite en 2010, lorsque Maltz a quitté Microsoft Research pour rejoindre Bing et contribuer à la création d’une équipe réseau. Cette étape a modifié la structure des incitations. Un article de recherche peut limiter ses affirmations à une expérience. Une équipe de production reste responsable de la latence, de la disponibilité, de la capacité et du coût après la publication de l’article. Ce changement a placé des ingénieurs formés à la recherche au sein d’une organisation de services où les décisions réseau avaient des conséquences commerciales immédiates.

VL2 a redéfini le réseau du centre de données comme un service de placement

L’article VL2 de 2009 constitue un repère important dans le parcours de recherche de Maltz. Sa question centrale n’était pas simplement de savoir comment construire une fabrique plus rapide. Il demandait quel service le réseau du centre de données devait fournir aux applications situées au-dessus de lui. La réponse prenait la forme d’une liberté de placement: les charges de travail devaient pouvoir s’exécuter sur les serveurs disponibles sans que le réseau impose des emplacements rigides ou expose des goulets d’étranglement persistants dus à la sursouscription.

VL2 associait une topologie physique de type Clos, une répartition des chemins et un modèle d’adressage séparant l’identité de l’application de son emplacement physique. Valiant Load Balancing distribuait le trafic entre les chemins disponibles, tandis qu’un mécanisme de résolution sur les systèmes terminaux associait les adresses de service aux emplacements réels. La conception visait une capacité élevée et uniforme entre les serveurs, ainsi que la possibilité de déplacer ou d’affecter des services sans renuméroter le réseau autour d’eux.

L’article présentait un prototype de 75 serveurs et des résultats expérimentaux délimités. Il ne documentait pas l’architecture exacte d’Azure aujourd’hui et ne doit pas être rétrospectivement présenté comme un déploiement complet à très grande échelle. Son importance est conceptuelle. Il traitait le réseau comme un ensemble de ressources devant rendre le placement informatique flexible, plutôt que comme une hiérarchie dont la topologie imposait l’emplacement des services.

Cette abstraction a des conséquences économiques directes. Un centre de données dont une partie de la capacité de calcul est inutilisable parce que certaines baies ont un mauvais accès réseau est moins utile que ne le laisse penser son nombre de serveurs. Une fabrique offrant de nombreux chemins et séparant l’identité de l’emplacement peut améliorer l’utilisation, simplifier l’extension des services et faciliter le contournement des pannes.

Le bénéfice dépend des schémas de trafic, de la capacité des liaisons et de la qualité du contrôle; il ne garantit pas sans condition une « bande passante de bissection complète » pour chaque charge de travail.

L’architecture transfère également de la complexité vers les terminaux et les systèmes de contrôle. L’adressage plat des services exige une résolution. Les chemins multiples nécessitent un hachage ou un ordonnancement évitant les collisions persistantes. Les pannes doivent être détectées et prises en compte dans le choix des chemins. Le diagnostic peut devenir plus difficile lorsque l’itinéraire d’un paquet dépend d’un état distribué plutôt que d’une hiérarchie fixe. La liberté de placement est produite par le logiciel; elle n’est pas accordée par la seule topologie.

L’influence à long terme de VL2 réside dans la manière dont il a relié la conception du réseau à l’ordonnancement du cloud. Le calcul, le stockage et le réseau ne peuvent pas être optimisés indépendamment lorsque les performances d’une charge de travail dépendent de communications collectives ou du trafic est-ouest. Le réseau devient une partie du contrat de placement. Cette idée est encore plus importante pour les grappes d’IA, où une tâche peut se bloquer parce qu’un chemin de communication ou un terminal se comporte différemment des autres.

Maltz était l’un des coauteurs d’une équipe importante. La valeur de l’article n’exige pas de lui attribuer chaque mécanisme. Il montre que ses travaux se situaient déjà à l’interface de l’architecture et des opérations: utiliser des exigences mesurées pour définir une abstraction de service, puis construire une part suffisante du système afin de vérifier la crédibilité de cette abstraction.

SNAP a traité le diagnostic réseau comme un problème de preuves entre plusieurs couches

La conception d’une fabrique à haute capacité ne facilite pas nécessairement le diagnostic des incidents applicatifs. Un service peut signaler une latence dont la cause sous-jacente est une liaison congestionnée, une interface réseau défaillante, un serveur surchargé, une dépendance distante de plusieurs niveaux ou un changement de configuration dont les effets franchissent les frontières organisationnelles. Les compteurs des équipements suffisent rarement à identifier la conséquence sur le service.

Les travaux sur SNAP ont abordé ce problème en mettant en corrélation les preuves applicatives et réseau dans un vaste environnement multiniveau. Ils ont étudié des milliers de serveurs et des centaines de composants applicatifs afin de relier les performances observées aux chemins et aux dépendances susceptibles de les expliquer. La méthode est importante parce qu’elle rejette l’idée qu’une seule couche de supervision détient la vérité.

Une équipe réseau voit les paquets, les interfaces et les routes. Une équipe applicative voit les requêtes, les files d’attente et les dépendances. Toutes deux peuvent avoir raison sur leurs données locales tout en étant en désaccord sur la causalité. Un diagnostic entre plusieurs couches exige un modèle commun indiquant quel composant applicatif utilisait quel chemin réseau à quel moment, et comment une panne ou une congestion a affecté le service.

La difficulté technique vient du fait que les données concernées utilisent des horloges, des identifiants et des politiques de conservation différents. Un enregistrement de flux peut agréger le trafic. Une trace applicative peut échantillonner les requêtes. L’état de la topologie change entre l’observation et l’enquête. Un serveur peut être déplacé ou remplacé. Une corrélation peut mettre en évidence des relations plausibles sans prouver qu’un événement en a causé un autre.

La valeur opérationnelle réside dans la réduction du champ de recherche. Un système montrant que plusieurs composants de service défaillants partagent un chemin ou un équipement donne aux ingénieurs un point de départ. Il peut aussi démontrer que le réseau n’était pas le facteur commun, ce qui réduit les escalades improductives. L’objectif n’est pas un moteur omniscient d’analyse des causes profondes, mais une meilleure circulation des preuves entre les équipes.

Cette lignée de diagnostic se poursuit dans les travaux ultérieurs d’Azure sur l’orientation des incidents et les systèmes opérationnels. À l’échelle du cloud, le nombre d’alertes peut dépasser le nombre d’ingénieurs capables de les interpréter. L’organisation doit décider quels signaux indiquent un domaine de défaillance commun, quelle équipe est responsable de l’action suivante et quelles preuves doivent être conservées pour l’examen postérieur à l’incident.

Le mandat actuel de Maltz donne à ce sujet une portée supérieure à celle d’une recherche historique. Une organisation couvrant les services réseau, les équipements physiques et les systèmes optiques a besoin de modèles d’incident entre plusieurs couches, car ses propres frontières créent des risques lors des transmissions de responsabilité. Si le DNS, les réseaux virtuels, le déport côté hôte et la fabrique relèvent d’équipes distinctes, le système d’exploitation de l’organisation doit relier leurs preuves lorsqu’un client observe un symptôme unique.

SWAN et OneWAN ont révélé les limites de l’optimisation centralisée

Les liaisons entre centres de données sont coûteuses, rares et difficiles à étendre rapidement. La demande de trafic varie selon le service et le moment. Les pannes peuvent supprimer de la capacité sans réduire le besoin d’émission des applications. Le routage distribué traditionnel maintient la connectivité du réseau, mais il n’attribue pas nécessairement la capacité longue distance en fonction des priorités commerciales ou de l’efficacité globale.

SWAN, publié en 2013, utilisait un contrôle logiciel pour répartir le trafic sur le réseau étendu de Microsoft. Il séparait le trafic prioritaire du trafic adaptable et cherchait à coordonner l’utilisation des liaisons à partir d’une vision globale. Le système reflétait la capacité d’un hyperscaler à contrôler à la fois le réseau et des parties importantes de la charge de travail, ce qui permettait de limiter le débit ou de replanifier certains trafics d’une manière qu’un fournisseur de transit ordinaire ne pourrait pas imposer à des clients indépendants.

L’intérêt du contrôle central est évident. Un contrôleur peut voir plusieurs chemins et éloigner le trafic flexible des liaisons rares. Il peut réserver une marge pour les pannes et donner la priorité aux services pour lesquels un retard aurait les conséquences les plus importantes. La capacité des liaisons peut être utilisée plus efficacement qu’avec un provisionnement statique prudent.

Les limites sont tout aussi structurelles. La vision du contrôleur n’est jamais parfaitement à jour. Les mesures arrivent tard et le réseau peut changer pendant le calcul d’une optimisation. Un système central peut tomber en panne ou émettre une politique globalement cohérente dans son modèle mais erronée au regard de l’état physique. Une exploitation sûre exige donc des chemins de secours, des changements délimités et des mécanismes distribués capables de préserver la connectivité lorsque le contrôleur n’est pas disponible.

OneWAN a ensuite traité le problème de la multiplicité des systèmes de contrôle des réseaux étendus et de la fragmentation des politiques. Les grandes organisations ne conservent pas éternellement un seul WAN homogène. Elles accumulent des réseaux, des contrôleurs, des classes de trafic et des pratiques opérationnelles. Une architecture unificatrice doit rapprocher ces systèmes sans supposer qu’ils peuvent tous être remplacés immédiatement.

Cette progression de SWAN à OneWAN illustre un schéma courant du cloud. La première génération démontre qu’un logiciel central peut optimiser un domaine. La génération suivante doit intégrer les différents optimiseurs, prendre en charge l’état hérité et créer une cohérence opérationnelle au-delà des frontières organisationnelles. Le réseau défini par logiciel ne supprime pas la complexité; il modifie l’endroit où elle s’exprime.

Pour Azure Networking, le WAN est aussi le lieu où le logiciel rencontre le capital de la manière la plus visible. Les routes de fibre, la capacité optique et les accords d’interconnexion ne peuvent pas évoluer à la vitesse du logiciel. Un contrôleur peut mieux utiliser les liaisons existantes, mais il ne peut pas créer des chemins physiques diversifiés pendant une panne. La direction du réseau doit donc relier la politique d’ingénierie du trafic à la planification à long terme des capacités et des routes.

Les recherches de Maltz sur les réseaux étendus placent à plusieurs reprises l’utilisation et la résilience au sein du même problème de conception. Un réseau exploité en permanence près de sa limite théorique peut sembler efficace jusqu’à ce qu’une panne supprime une liaison. Une marge n’est pas du gaspillage lorsqu’elle préserve le service. La cible opérationnelle correcte dépend de la probabilité de panne, de la flexibilité du trafic et du coût d’un retard dans l’ajout de capacité.

CrystalNet a transféré les changements réseau dans un environnement de test inspiré du logiciel

Les réseaux cloud évoluent en permanence. De nouveaux micrologiciels de commutateurs, politiques de routage, ACL, tunnels et fonctions de service arrivent dans des environnements dont l’état complet ne peut pas être reproduit avec quelques équipements de laboratoire. L’examen traditionnel des changements — lecture de la configuration et recours à l’expérience des opérateurs — ne passe pas à l’échelle face au nombre d’interactions d’un réseau à très grande échelle.

CrystalNet et les travaux connexes sur la vérification des réseaux ont abordé le changement comme un problème de test logiciel. Un réseau de production, ou une partie importante de celui-ci, pouvait être émulé dans un environnement contrôlé. Les changements proposés pouvaient être exécutés sur une topologie et une configuration réalistes avant d’atteindre le parc. Des techniques formelles et fondées sur des modèles pouvaient vérifier des propriétés définies, tandis que l’émulation pouvait révéler des comportements d’implémentation omis par un modèle abstrait.

La distinction entre le modèle et l’implémentation est essentielle. Un vérificateur peut prouver qu’une politique de routage respecte l’accessibilité dans son modèle, alors qu’un défaut du micrologiciel d’un commutateur enfreint ce modèle en pratique. Un émulateur peut reproduire le logiciel réel tout en passant à côté de contraintes de temporisation matérielle, d’échelle ou de combinaisons de pannes. Aucune technique unique ne prouve la sûreté de l’ensemble du réseau.

La valeur vient de la superposition des contrôles. L’analyse statique peut rejeter les violations évidentes d’une politique. L’émulation peut exécuter les logiciels réels et tester les procédures. Un déploiement canari peut exposer un changement à une part limitée du trafic de production. La télémétrie peut détecter les écarts. Le retour en arrière peut limiter les dommages. Chaque étape repose sur une base de confiance différente et détecte une catégorie d’erreur distincte.

CrystalNet exigeait aussi une infrastructure que de nombreuses organisations sous-estiment. Une émulation fidèle nécessite des images, des configurations, une topologie, des systèmes de contrôle et un trafic représentatif à jour. Si l’environnement de test diverge de la production, un résultat positif peut créer une fausse confiance. La maintenance du laboratoire devient une partie du processus de publication du réseau, et non un projet de recherche ponctuel.

L’association de Maltz à ces travaux renforce le thème organisationnel. La vérification n’est pas un outil acheté par l’équipe réseau et appliqué à la fin. Elle exige que les équipes produit expriment leur intention, que les équipes chargées des équipements exposent leur état, que les opérations fournissent des cas d’incident et que la direction décide quelles propriétés bloquent un déploiement. Le système de test devient un contrat institutionnel sur ce qui constitue un changement acceptable.

Les sources publiques ne révèlent pas chaque panne d’Azure ni la couverture précise de la vérification actuelle. Les contraintes de sécurité et de concurrence rendent cette transparence improbable. La conclusion défendable est que les chercheurs et ingénieurs de Microsoft ont développé des systèmes destinés à faire passer les changements réseau par une chaîne d’assurance plus proche de celle du logiciel. Leur réussite doit être évaluée d’après la couverture, le risque de fausse confiance et l’usage opérationnel, et non d’après la seule existence d’un article sur la vérification.

AccelNet a déplacé les réseaux virtuels des processeurs hôtes vers du matériel programmable

Les réseaux virtuels consomment des ressources de calcul. Un hôte cloud doit appliquer l’encapsulation, la politique de sécurité, l’équilibrage de charge, la mesure et d’autres fonctions aux paquets entrant dans les machines virtuelles ou en sortant. Lorsque ces opérations s’exécutent entièrement sur les processeurs généralistes du serveur, elles concurrencent les charges de travail des clients et peuvent produire des performances variables.

Azure Accelerated Networking, documenté dans l’article AccelNet de 2018, a déplacé des parties importantes du chemin de données du réseau virtuel vers des SmartNIC programmables fondées sur des FPGA. La conception cherchait à préserver la souplesse des réseaux définis par logiciel tout en exécutant les opérations courantes sur les paquets dans du matériel proche de l’interface réseau.

Le mécanisme économique est simple. Les cycles de processeur rendus à l’hôte peuvent être vendus ou utilisés pour le calcul au lieu de servir aux surcoûts d’infrastructure. Le déport peut rendre la latence et le débit plus prévisibles, car le traitement des paquets est moins exposé à l’ordonnancement de l’hôte et à la concurrence entre charges de travail. Le fournisseur cloud peut mettre à jour la chaîne programmable sans remplacer une carte réseau à fonction fixe à chaque modification de politique.

Le compromis d’ingénierie est moins simple. Une chaîne matérielle dispose d’un nombre limité d’étapes, de mémoire et de temps. Elle nécessite une représentation de la politique du réseau virtuel qui puisse être compilée et mise à jour en toute sécurité. L’état doit rester cohérent avec le plan de contrôle. Une défaillance de la SmartNIC peut affecter la connectivité de chaque charge de travail de l’hôte. Le diagnostic traverse l’hôte, le micrologiciel de la carte, la logique du FPGA et le service réseau.

L’article AccelNet faisait état d’un déploiement à une échelle importante dans Azure et d’une disponibilité pour les clients ayant commencé avant sa publication. Ses chiffres appartiennent à cette période. Ils ne doivent pas être transformés en décompte du parc de 2026 ni être supposés décrire les générations ultérieures de DPU. Les preuves sont particulièrement solides comme récit de première main d’une architecture déployée et de résultats mesurés avec le matériel et les charges de travail de l’article.

Le système a marqué une évolution plus large de l’infrastructure cloud. La fonction réseau n’était plus située au moyen d’une simple distinction entre logiciel et matériel. Elle était répartie. Une partie de la politique restait dans des contrôleurs distribués, une autre dans le logiciel hôte, une autre dans la logique programmable de la carte réseau et une autre encore dans les commutateurs. La meilleure frontière dépendait de la latence, de la fréquence des mises à jour, de l’état, de la sécurité et du silicium disponible.

Cette répartition crée un problème de compatibilité à long terme. Les nouvelles fonctions du réseau virtuel doivent fonctionner avec les anciennes et les nouvelles générations de déport, ou revenir au logiciel. Un parc peut contenir plusieurs cartes et configurations d’hôte. Le plan de contrôle doit connaître les capacités présentes et préserver un comportement cohérent entre elles. L’accélération matérielle peut réduire le coût par paquet tout en augmentant le nombre de variantes qu’une organisation doit prendre en charge.

Le périmètre organisationnel actuel de Maltz comprend précisément ces frontières. Les SmartNIC ne constituent pas un programme d’équipement isolé lorsque leur chaîne met en œuvre une sécurité et une sémantique réseau visibles par les clients. Elles font partie du contrat de service. Les décisions sur les fonctions à déporter doivent donc être prises avec les équipes responsables des API, de la fiabilité et du cycle de vie du parc.

SONiC a fait du logiciel de commutation une couche stratégique pour l’opérateur

Historiquement, les commutateurs physiques étaient livrés sous forme de produits intégrés: matériel, système d’exploitation réseau, interface en ligne de commande et assistance du fournisseur. Les hyperscalers souhaitaient mieux contrôler le comportement logiciel et pouvoir utiliser des puces standard issues de plusieurs fournisseurs. SONiC, l’écosystème open source de logiciels de commutation fortement associé à Microsoft, dissocie la pile logicielle d’une plateforme de commutation propriétaire unique.

Cette dissociation peut élargir le choix des fournisseurs. Un opérateur peut développer un seul environnement de contrôle et de gestion pour plusieurs matériels compatibles. Les bogues et les fonctions peuvent être examinés en amont. L’automatisation peut cibler des interfaces communes au lieu de plusieurs interfaces en ligne de commande propres aux fournisseurs. Son échelle donne à un hyperscaler un levier pour exiger des fournisseurs de silicium et de plateformes qu’ils prennent en charge le modèle logiciel.

La dissociation ne rend pas le matériel interchangeable. Les ASIC de commutation exposent des tables, des tampons, une télémétrie, des mécanismes de mise en file d’attente et des comportements de défaillance différents. Les pilotes de plateforme et les couches d’abstraction doivent faire correspondre ces différences. Une fonction peut exister dans SONiC tout en dépendant du SDK d’un fournisseur ou d’une capacité matérielle. Les tests doivent couvrir chaque combinaison prise en charge.

La charge opérationnelle se déplace elle aussi. Un fournisseur intégré certifie sa propre image et son propre matériel. Un hyperscaler qui maintient une distribution SONiC doit assembler les composants, gérer les versions, tester les régressions et coordonner les correctifs entre les projets en amont et les fournisseurs. Le résultat peut être plus adaptable et moins dépendant d’un seul fournisseur, mais uniquement parce que l’opérateur a construit une organisation produit interne autour du logiciel de commutation.

Maltz ne doit pas être présenté comme l’unique créateur ou propriétaire de SONiC. Il s’agit d’un projet communautaire auquel contribuent de nombreuses entreprises et de nombreux ingénieurs. Sa pertinence vient du fait qu’il dirige une organisation qui utilise le logiciel de commutation comme une couche d’un réseau de bout en bout et qui peut orienter ses priorités par l’échelle de ses déploiements et sa participation technique.

L’open source soulève une question de gouvernance. Microsoft bénéficie des améliorations apportées aux composants partagés par d’autres fournisseurs et opérateurs. Les autres entités bénéficient de code développé pour des problèmes à l’échelle d’Azure. Pourtant, les besoins d’Azure peuvent différer de ceux de réseaux plus petits, et Microsoft peut maintenir des différences en aval qui ne sont pas visibles en amont. L’ouverture du projet ne garantit ni une influence égale ni des distributions identiques.

L’effet opérationnel peut néanmoins être important. Lorsque le micrologiciel des commutateurs devient une couche contrôlée par l’opérateur, l’innovation réseau peut avancer sans attendre une version logicielle complète du fournisseur. Cette rapidité est utile pour la télémétrie, l’automatisation et les nouvelles architectures de centres de données. Elle signifie aussi qu’une mauvaise décision logicielle peut se propager dans un vaste parc. La discipline appliquée par CrystalNet aux changements réseau devient essentielle pour la chaîne d’approvisionnement du logiciel de commutation elle-même.

DASH SmartSwitch demande quelles fonctions doivent résider dans l’équipement de haut de baie

L’article SONiC DASH SmartSwitch de 2026 représente une étape ultérieure du débat sur le déport. Au lieu de placer chaque fonction de service cloud sur une SmartNIC ou un DPU hôte, l’architecture transfère certaines fonctions vers une conception intégrée au commutateur. L’article décrit une chaîne immuable adaptée au matériel ainsi qu’une approche « uni-box » faisant converger les ressources de traitement réseau et de DPU.

L’intérêt réside dans la consolidation. Un équipement de haut de baie peut desservir plusieurs hôtes et réduire la duplication du matériel de déport, de la consommation électrique ou de l’espace occupé. Les fonctions mises en œuvre dans une chaîne contrainte peuvent fonctionner à haut débit avec un comportement prévisible. La gestion peut être simplifiée lorsque moins d’accélérateurs par hôte nécessitent une prise en charge de leur cycle de vie.

La contrainte est la programmabilité. Une chaîne immuable ou strictement définie est plus facile à vérifier et à optimiser qu’un équipement programmable sans limites strictes, mais elle ne peut pas absorber toutes les nouvelles fonctions. Les services cloud évoluent. Les politiques de sécurité, les encapsulations et le comportement d’équilibrage de charge peuvent changer plus vite que le matériel. Une conception qui accélère les fonctions courantes doit offrir un chemin sûr pour les exceptions et les besoins futurs.

L’article fait état d’un déploiement en production et de résultats importants en matière de performances ou d’efficacité. Il s’agit de déclarations de première main significatives, et non de références universelles indépendantes. Les sources publiques n’exposent pas l’ensemble de la répartition géographique du déploiement, des charges de travail, de la base de comparaison ni de tous les coûts transférés ailleurs dans le système. Un gain au niveau du commutateur pourrait nécessiter une plus grande complexité du plan de contrôle ou limiter un service futur.

L’architecture illustre donc la question d’ingénierie centrale relevant du mandat de Maltz: où une fonction doit-elle s’exécuter? Le logiciel hôte offre souplesse et puissance de calcul générale, mais consomme du processeur et ajoute de la gigue. Une SmartNIC ou un DPU isole le travail près du serveur et peut être programmable, mais ajoute du matériel et des variantes dans le parc. Un commutateur partage l’accélération entre les hôtes et peut améliorer la consolidation, tout en imposant une chaîne plus stricte et un domaine de défaillance plus large.

Il n’existe pas de réponse permanente. La charge de travail, le silicium et les exigences du service déplacent la frontière. L’organisation a besoin d’une méthode de décision: quantifier le coût de l’emplacement actuel, définir la sémantique à préserver, modéliser les conséquences d’une panne, tester la nouvelle implémentation et conserver une solution de secours pour les cas non pris en charge.

DASH SmartSwitch doit donc être considéré comme une génération dans la répartition continue du réseau cloud, et non comme la convergence finale de la commutation et du déport. Son importance tient au fait qu’il montre qu’Azure est disposé à redéfinir la frontière des équipements lorsque l’économie du parc le justifie, et que SONiC fournit un environnement logiciel permettant d’intégrer cette redéfinition.

Les systèmes optiques empêchent l’organisation logicielle de considérer la bande passante comme une abstraction

Le contrôle défini par logiciel peut attribuer des chemins et le déport peut réduire le coût par paquet, mais un réseau cloud dépend en dernier ressort de liaisons physiques. Les routes de fibre, les transpondeurs, les systèmes optiques cohérents, les ports de commutation et l’alimentation déterminent la capacité disponible et les endroits où elle peut être acheminée. La description d’Azure Networking par Microsoft inclut les systèmes optiques parce que les couches logicielles ne peuvent pas être planifiées indépendamment de ces contraintes.

La capacité optique présente de longs délais de mise en œuvre. Une fonction du plan de contrôle peut être déployée en quelques semaines; une nouvelle route peut nécessiter des autorisations, des travaux de construction, des approvisionnements et des tests. Même lorsqu’une fibre existe, le choix des transpondeurs et des systèmes de ligne influe sur la portée, la consommation et les possibilités de mise à niveau. La redondance dépend de la diversité physique, et non du tracé de deux lignes logiques dans le même conduit.

Une organisation couvrant le logiciel et les systèmes optiques peut relier la prévision de la demande à la conception du réseau. Elle peut déterminer quels services génèrent le trafic, décider où ajouter de la capacité et construire des systèmes de contrôle utilisant les contraintes réelles de la topologie. Elle peut aussi coordonner la maintenance pour que le routage logiciel ne suppose pas une diversité absente du réseau physique.

Les sources publiques ne fournissent pas une carte complète de l’empreinte d’Azure en matière de fibre, de commutateurs ou de systèmes optiques, et il serait inapproprié d’en déduire une à partir de l’expression « pétabits de connectivité ». De telles descriptions établissent une échelle considérable sans révéler la topologie, la distribution régionale ou la capacité disponible. La sécurité et la sensibilité commerciale justifient légitimement cette divulgation limitée.

Le risque lié à la chaîne d’approvisionnement demeure visible, même dans une pile fortement personnalisée. Microsoft dépend de fonderies, de puces de commutation, de composants optiques et d’usines de fabrication. Un logiciel de commutation ouvert ne crée pas une deuxième source pour un module optique spécialisé. Une chaîne SmartSwitch personnalisée peut accroître la dépendance à une génération particulière de silicium. La direction de l’infrastructure doit décider où la personnalisation améliore le pouvoir de négociation et où elle réduit l’éventail des fournisseurs.

L’énergie constitue une autre frontière physique. Les commutateurs, les systèmes optiques, les cartes réseau et le refroidissement consomment de l’énergie avant même qu’une charge de travail client ne s’exécute. Le déplacement d’une fonction du processeur hôte vers un DPU ou un commutateur peut économiser de l’énergie dans un équipement et en ajouter dans un autre. La mesure pertinente est le service utile fourni par unité de consommation totale du système, y compris la capacité inutilisée et la redondance.

Le mandat organisationnel de Maltz laisse penser que ces compromis doivent être examinés ensemble. Le réseau n’est pas une surcouche logicielle flottant au-dessus d’un matériel interchangeable. C’est un système d’investissement dont le logiciel détermine l’efficacité d’utilisation des actifs physiques et dont le matériel détermine quelles abstractions logicielles sont crédibles.

Les articles de recherche constituent des preuves, mais Microsoft contrôle une grande partie du champ de preuves

Les publications sur le réseau d’Azure sont particulièrement précieuses, car elles décrivent des systèmes que de nombreux fournisseurs cloud garderaient entièrement privés. Les articles sur VL2, SWAN, AccelNet, CrystalNet, OneWAN et DASH exposent des architectures, des choix de conception et des mesures délimitées. Ils permettent au secteur de débattre des mécanismes au lieu de s’appuyer uniquement sur des affirmations commerciales.

Ils restent des divulgations contrôlées par leur auteur institutionnel. Microsoft choisit les systèmes qu’il publie, les incidents qu’il décrit et les références auxquelles il se compare. Un article peut signaler un déploiement en production sans révéler la proportion du parc, les sites concernés ou les problèmes opérationnels rencontrés ultérieurement. Des résultats de performance peuvent être rigoureux dans le cadre d’un test tout en omettant des coûts situés hors de ses limites.

Cela ne rend pas les preuves peu fiables. L’évaluation par les pairs, une méthodologie détaillée et des auteurs nommés fournissent un appui plus solide qu’une page produit dépourvue de sources. La discipline correcte consiste à rattacher chaque affirmation à sa période et à son périmètre. Le chiffre d’un million d’hôtes d’AccelNet décrit l’architecture et l’état du parc rapportés en 2018. La déclaration de production de DASH décrit le déploiement que les auteurs de 2026 étaient en mesure de révéler. Aucun des deux ne doit être transformé en recensement actuel complet.

La même règle s’applique à la qualité d’auteur de Maltz. Le fait qu’un article le mentionne comme coauteur établit sa participation aux recherches. Cela ne précise pas le composant qu’il a mis en œuvre ni la décision qu’il a prise, sauf indication de l’article. Son titre actuel établit une responsabilité organisationnelle, et non la paternité personnelle de chaque service. L’attribution doit respecter la forme des preuves sans l’exagérer.

Les comparaisons indépendantes sont difficiles, car les hyperscalers publient des fragments différents de leurs réseaux. Les articles de Google sur Jupiter et Andromeda, les divulgations d’AWS et les bancs d’essai de DPU des fournisseurs utilisent des matériels, des périodes et des charges de travail différents. Construire un classement à partir de ces éléments créerait une fausse précision. La comparaison la plus utile consiste à demander quelle couche chaque opérateur contrôle et quels compromis il a choisi de révéler.

Le secret opérationnel crée un problème de responsabilité non résolu. Les clients dépendent du réseau d’Azure, mais ne peuvent pas examiner sa conception complète ni l’ensemble de ses incidents. Le fournisseur offre des engagements de service et certaines preuves techniques. Les clients doivent décider quel degré de dépendance ils acceptent et quels contrôles multirégion, multicloud ou applicatifs ils doivent conserver en dehors du fournisseur.

Le profil de Maltz peut éclairer cette structure sans prétendre la résoudre. Son rôle montre où se situe la responsabilité d’ingénierie au sein de Microsoft. Les preuves publiques peuvent montrer la filiation des recherches et le périmètre organisationnel. Elles ne peuvent pas révéler aux observateurs extérieurs chaque décision, chaque budget ou chaque résultat de fiabilité. Ces limites font partie du modèle cloud; ce ne sont pas des lacunes qu’un journaliste devrait combler par déduction.

L’infrastructure personnalisée modifie les coûts en déplaçant le travail entre les frontières

La justification économique de la pile réseau d’Azure est souvent décrite au moyen de mécanismes d’efficacité. Une fabrique Clos peut améliorer le placement et l’utilisation de la capacité. Le contrôle logiciel du WAN peut mieux exploiter les liaisons coûteuses. Les SmartNIC peuvent restituer le processeur de l’hôte aux charges de travail des clients. SONiC peut élargir l’écosystème des fournisseurs de commutateurs. La vérification peut réduire le coût des mauvais changements. Un SmartSwitch peut consolider le déport.

Chaque mécanisme comporte un coût interne correspondant. Une fabrique personnalisée exige des logiciels de contrôle et d’exploitation. Un contrôleur WAN central nécessite une télémétrie précise et des solutions de repli sûres. Les SmartNIC ajoutent du développement matériel et de la gestion de parc. SONiC exige intégration et certification. Les environnements de vérification doivent être entretenus. Une chaîne de commutation contrainte peut créer de futurs travaux fonctionnels.

Microsoft ne publie pas de modèle de coût complet pour Azure Networking, et le titre de Maltz ne révèle ni budget ni économie d’unité opérationnelle. Il serait spéculatif d’affirmer qu’un système particulier a réduit le coût total d’Azure selon un pourcentage universel. Les articles peuvent établir des gains locaux de ressources dans les conditions documentées. La conséquence commerciale dépend du prix du matériel, du travail d’ingénierie, de l’utilisation, du taux de défaillance et de la part des ressources économisées qui devient une capacité vendable.

Un avantage stratégique potentiel réside autant dans la vitesse d’apprentissage que dans le coût unitaire. Un fournisseur contrôlant plusieurs couches peut observer un goulet d’étranglement, modifier l’architecture et déployer le résultat sans attendre la feuille de route d’un fournisseur. AccelNet et DASH suggèrent une succession au cours de laquelle Azure a déplacé à plusieurs reprises des fonctions de traitement des paquets à mesure que le matériel et les charges de travail évoluaient. La capacité à mener cette expérience à l’échelle du parc produit des connaissances que les concurrents ne peuvent pas acheter immédiatement.

L’inconvénient est la dépendance organisationnelle à des systèmes compris par peu de personnes extérieures. Les fournisseurs commerciaux répartissent les coûts de développement entre leurs clients et maintiennent des écosystèmes d’assistance. Une conception personnalisée d’hyperscaler peut disposer d’une documentation externe limitée et d’un vivier restreint de compétences. Si des responsables ou des équipes clés partent, l’entreprise doit préserver en interne les connaissances architecturales et la discipline opérationnelle.

C’est pourquoi la succession appartient à la discussion sur les coûts. Un réseau constitué de plans de contrôle, de micrologiciels et de mécanismes de déport personnalisés ne peut pas dépendre de la mémoire d’une personne. Les relevés de décisions, les interfaces, les tests et les responsabilités doivent survivre aux réorganisations. Les sources publiques ne décrivent pas en détail la délégation sous Maltz; un profil ne peut donc pas déterminer si le risque de succession est élevé ou faible. Il peut identifier le problème structurel créé par un vaste mandat.

L’économie des réseaux cloud porte donc moins sur le choix entre personnalisé et standard que sur la décision des endroits où personnaliser. Azure combine des normes, des composants standard, des logiciels open source et des systèmes propriétaires. Le contrôle des interfaces lui permet de remplacer ou d’optimiser certaines couches. La valeur totale dépend de la capacité de l’organisation à maintenir ces choix au-delà du cycle matériel qui les a justifiés.

Le dirigeant responsable n’est ni un architecte solitaire ni un titre symbolique

Technical Fellow peut sembler être un titre honorifique réservé à un chercheur éloigné des opérations. La description actuelle de Maltz par Microsoft ne confirme pas cette interprétation. Elle associe ce titre à celui de Corporate Vice President et à un mandat d’ingénierie explicite couvrant les services déployés et les systèmes physiques. Le poste est à la fois technique et organisationnel.

Cette combinaison reflète une évolution plus large de la direction des infrastructures. Un ingénieur réseau principal pouvait autrefois être principalement responsable de la conception du routage, de la sélection des fournisseurs et des opérations. Chez un fournisseur cloud, le mandat comprend les systèmes distribués, la sécurité, les micrologiciels, le silicium programmable, la planification des capacités et la chaîne d’approvisionnement. Une décision dans un domaine peut modifier le comportement visible par les clients dans un autre.

Le rôle continue de s’exercer par délégation. La sécurité réseau, le DNS, les réseaux virtuels, SONiC, la fabrique et les systèmes optiques nécessitent chacun des responsables spécialisés. L’autorité de Maltz s’exprime probablement dans les examens d’architecture, les priorités, la conception organisationnelle et les escalades, plutôt que par un contrôle direct de chaque implémentation. Les preuves publiques ne révèlent pas les droits de décision exacts, qui doivent donc rester indéterminés.

Son parcours de chercheur donne au rôle une méthode distinctive. Les systèmes associés à sa carrière ont tendance à partir de mesures ou de contraintes opérationnelles, à définir une nouvelle abstraction, à construire une implémentation fonctionnelle et à publier des résultats délimités. Cette méthode convient à l’ingénierie à très grande échelle parce qu’elle relie la théorie aux preuves issues du parc. Elle peut également privilégier les problèmes que Microsoft est en mesure de mesurer et de divulguer.

L’évaluation la plus défendable de son influence distingue donc trois formes. La qualité d’auteur d’un article montre sa participation à des systèmes documentés. Ses fonctions historiques dans des équipes montrent son passage de la recherche aux réseaux de production. Le profil actuel de Microsoft montre sa responsabilité exécutive pour Azure Networking. Ensemble, ces éléments étayent un récit d’élargissement de l’autorité d’intégration. Ils ne permettent pas d’attribuer chaque innovation réseau d’Azure à une seule personne.

Cette distinction protège les contributions des ingénieurs et des communautés entourant les systèmes. SONiC dispose d’une gouvernance communautaire. Les normes P4 et Ethernet sont développées ailleurs. Les fournisseurs de matériel construisent le silicium et les systèmes optiques. Les clients exploitent des applications dont le comportement façonne la demande. Azure Networking coordonne ces dépendances, mais ne les possède pas toutes.

La direction est importante précisément parce que les dépendances ne peuvent pas être réduites à un seul ensemble. Quelqu’un doit décider quelles interfaces Microsoft contrôle, lesquelles il normalise, lesquelles il achète et lesquelles il laisse aux communautés en amont. Le rôle de Maltz le place près de ces décisions, tandis que les preuves accessibles au public en décrivent plus clairement le périmètre que le processus interne.

Le DNS et la sécurité réseau rendent le mandat d’Azure visible aux clients

Les parties les plus visibles d’un réseau cloud ne sont souvent ni les liaisons ni les commutateurs. Un client constate si un nom est résolu, si un réseau virtuel est accessible, si une politique de sécurité est appliquée et si le trafic suit le chemin prévu entre les services. La description de l’organisation de Maltz par Microsoft inclut la sécurité réseau et le DNS aux côtés du contrôle logiciel et physique. Ce périmètre est important parce qu’il place la sémantique des services destinés aux clients dans la même chaîne d’ingénierie que l’infrastructure sous-jacente.

Le DNS est une dépendance distribuée dotée d’une interface trompeusement simple. Une application demande un nom et reçoit une réponse, mais le chemin peut comprendre des données faisant autorité, la mise en cache, le transfert, des zones privées, la découverte de services et des politiques. Une organisation réseau responsable du DNS doit distinguer une défaillance de nommage d’une défaillance de transport tout en préservant la disponibilité lors des changements du plan de contrôle. Un système de routage peut être sain alors qu’un service reste inaccessible parce que le nom pointe vers des informations anciennes ou erronées.

Inversement, un incident DNS peut provoquer des déplacements de trafic ressemblant à un événement réseau.

La politique de sécurité introduit un problème comparable entre plusieurs couches. Un client cloud peut exprimer son intention par l’intermédiaire de politiques de sécurité réseau et de réseau virtuel. La plateforme doit traduire cette intention en mesures appliquées sur les hôtes, les SmartNIC, les commutateurs ou les équipements de service. Le meilleur emplacement dépend de la latence, de l’état, des exigences fonctionnelles et du comportement en cas de défaillance.

Placer l’application des règles dans du matériel programmable peut réduire le surcoût du processeur; la placer trop loin de la charge de travail peut faire perdre le contexte d’identité. La dupliquer entre plusieurs couches peut produire des décisions incohérentes.

La difficulté d’ingénierie ne consiste pas seulement à vérifier qu’une règle fonctionne. Les plans de contrôle du cloud changent en permanence. Des ressources apparaissent et disparaissent, les adresses se déplacent, les locataires mettent à jour leurs politiques et des services régionaux tombent en panne. Le plan de données doit recevoir rapidement le bon état sans qu’une mise à jour partielle crée une ouverture involontaire ou une interruption. Cela exige un versionnage, une réconciliation et un moyen de déterminer quelle version de politique a traité une connexion.

Le regroupement du DNS, de la sécurité et du réseau physique dans une vaste organisation peut réduire les défaillances lors des transmissions de responsabilité. L’équipe qui conçoit un réseau virtuel peut se coordonner avec celle qui met en œuvre le déport côté hôte et avec celle qui exploite la fabrique. Les responsables d’incident peuvent suivre une dépendance entre les couches sans traverser plusieurs contrats fournisseurs. C’est un avantage potentiel de la maîtrise à très grande échelle.

Cette concentration augmente aussi le rayon d’impact des hypothèses organisationnelles. Un modèle d’identité, un compilateur de politiques ou un service de contrôle partagé peut affecter de nombreux produits. La centralisation crée également des conflits de priorité: une modification améliorant un service peut imposer une complexité supplémentaire au plan de données commun. Le dirigeant responsable a besoin de mécanismes d’examen indépendant et d’exceptions propres aux services sans permettre à chaque équipe de créer sa propre version de la plateforme.

Les preuves publiques ne révèlent pas la répartition interne des responsabilités ni leur division exacte au sein d’Azure Networking. La conclusion défendable est plus étroite. Le mandat de Maltz, tel que Microsoft le décrit, relie les services réseau visibles par les clients aux systèmes et équipements qui les appliquent. L’intégration organisationnelle devient ainsi une composante de la fiabilité du service, et non un simple détail de rattachement interne.

Le déploiement dans le parc transforme l’architecture de recherche en obligation opérationnelle

Nombre des systèmes associés à Maltz ont été présentés dans des articles de recherche. VL2, SWAN, CrystalNet, AccelNet et les travaux de 2026 sur DASH SmartSwitch décrivent des architectures et publient des résultats délimités. Leur importance en production dépend d’un processus que les articles ne peuvent révéler que partiellement: la qualification et le déploiement dans le parc.

Un cloud ne peut pas mettre à jour simultanément tous les hôtes, commutateurs ou régions. Les générations matérielles diffèrent, les versions des micrologiciels et des pilotes varient, et les charges de travail des clients utilisent des fonctions que l’évaluation initiale peut ne pas couvrir. Une nouvelle fonction réseau passe donc par des laboratoires, des émulations, des déploiements canaris, des grappes sélectionnées puis une diffusion plus large. Chaque étape nécessite des critères de poursuite et des preuves que le retour en arrière reste possible.

CrystalNet est pertinent parce qu’il traite le réseau comme un système pouvant être émulé et testé avant un changement. L’usage le plus solide d’un tel système ne consiste pas à certifier définitivement une conception. Il consiste à comparer un état proposé aux hypothèses actuelles de la production, à générer des cas de défaillance et à découvrir des dépendances inconnues du responsable du changement. Le modèle doit être mis à jour après les incidents, faute de quoi il devient une copie rassurante d’un réseau plus ancien.

Le déport matériel rend le déploiement plus exigeant. AccelNet a transféré des fonctions du réseau virtuel vers des SmartNIC FPGA, et les conceptions ultérieures de DPU ou de SmartSwitch poursuivent ce transfert. Un correctif logiciel autrefois déployable par un agent hôte peut désormais nécessiter un micrologiciel, une réinitialisation de l’équipement ou une qualification propre à la cible. La plateforme a besoin d’une compatibilité entre le logiciel hôte, le programme de l’équipement et le schéma du plan de contrôle. Les générations mixtes doivent produire une sémantique équivalente pour les clients, même si leurs implémentations diffèrent.

Un parc modifie aussi l’économie des petits défauts. Une fuite de mémoire, une copie supplémentaire de paquet ou une nouvelle tentative du plan de contrôle peut être négligeable sur une machine et importante à l’échelle d’une région. Inversement, une amélioration dans un banc d’essai peut ne pas réduire le coût total si elle augmente la charge opérationnelle ou restreint le choix des fournisseurs. Les données de déploiement doivent donc inclure les ressources processeur rendues aux charges de travail, la latence de longue traîne, les taux de défaillance des équipements, le temps de réparation et le coût du maintien de plusieurs générations.

Le rôle de Maltz comme responsable de l’ingénierie diffère ici de celui d’un auteur d’article. Une organisation qui développe, déploie et exploite le réseau doit assumer le résultat après la publication. Elle doit décider quand les preuves sont suffisantes, quelles régressions sont acceptables et comment contenir une conception qui se comporte différemment à grande échelle. Ces décisions sont réparties entre les équipes, mais le mandat organisationnel crée un point de responsabilité.

Les sources publiques étayent des exemples de recherche orientée vers la production ainsi que la déclaration de responsabilité de Microsoft. Elles ne fournissent ni recensement indépendant du parc ni historique interne des incidents. Un profil prudent doit donc décrire le déploiement comme le mécanisme reliant les travaux, sans affirmer que chaque architecture figurant dans les publications est devenue la conception universelle d’Azure.

L’intégration verticale transforme le risque fournisseur au lieu de l’éliminer

Le contrôle d’Azure sur le logiciel de commutation, la logique des SmartNIC et les services réseau peut réduire sa dépendance aux fournisseurs d’équipements réseau intégrés. SONiC permet de séparer le logiciel de commutation du matériel, tandis que les équipements programmables permettent à Microsoft de placer les fonctions là où son architecture l’exige. Cela peut renforcer son pouvoir de négociation et accélérer des changements qui, autrement, attendraient la feuille de route d’un fournisseur.

Le système physique dépend toujours de fournisseurs. Les ASIC de commutation, les cartes réseau, les DPU, les systèmes optiques, les câbles et les capacités de fabrication proviennent d’écosystèmes externes. Un logiciel ouvert ne rend pas deux composants interchangeables lorsque leur télémétrie, leur comportement des tampons, leurs modes de défaillance ou leur micrologiciel diffèrent. Un cloud qui écrit une plus grande part de la pile assume le travail d’intégration auparavant effectué par un fournisseur d’équipements.

La diversité des fournisseurs nécessite donc un contrat commun et des tests continus. Une deuxième source qui compile le même logiciel mais se comporte différemment en cas de congestion ne constitue pas un véritable substitut. Des composants optiques aux débits nominaux identiques peuvent différer par leur portée, leurs propriétés thermiques ou leurs défaillances. Un DPU peut exposer une fonction similaire à travers un modèle de contrôle différent. L’organisation réseau doit décider quelles différences sont acceptables et lesquelles doivent être masquées aux services.

L’intégration verticale peut également créer une dépendance interne. Un plan de contrôle propriétaire peut devenir si étroitement adapté à une génération de matériel qu’un changement de fournisseur exige une nouvelle conception. Les interfaces d’une organisation peuvent devenir aussi contraignantes que celles d’un fournisseur si elles ne sont pas documentées ou si elles sont contrôlées par un petit groupe. La succession et les outils deviennent alors des enjeux de chaîne d’approvisionnement.

L’avantage stratégique n’est pas une indépendance absolue. Il réside dans la capacité à choisir où se situe la dépendance et à rendre une plus grande part de l’interface visible. Le vaste mandat de Maltz place ces choix au sein d’une même organisation d’ingénierie. Le véritable test consiste à savoir si cette organisation préserve des solutions de remplacement tout en recherchant les gains de performance de l’intégration personnalisée.

Le commandement des incidents doit traverser les mêmes couches que l’architecture

Une pile réseau intégrée verticalement modifie l’organisation nécessaire lors des incidents. Un client signale une perte de connectivité, mais le symptôme immédiat peut provenir du DNS, d’une politique de réseau virtuel, d’un programme de déport côté hôte, d’une route de commutateur, d’une panne optique ou du service de contrôle distribuant l’état. Confier le cas à une seule équipe chargée d’un équipement peut retarder le diagnostic, car chaque couche peut sembler localement plausible.

Une organisation de bout en bout a besoin d’une chronologie commune des événements et d’identifiants qui survivent à la traduction entre les couches. Un changement de réseau virtuel doit pouvoir être relié à l’état des hôtes et des commutateurs. La version du micrologiciel d’une SmartNIC doit apparaître dans la même enquête que la politique qu’elle applique. Les alertes optiques doivent être corrélées avec l’ingénierie du trafic au lieu d’être traitées comme des relevés distincts d’installations. Cela n’exige pas une base de données universelle, mais des interfaces permettant de joindre les preuves.

La structure de commandement doit aussi préserver une contestation indépendante. Lorsqu’une même organisation possède la conception et l’exploitation, son modèle interne peut s’auto-confirmer. Une équipe ayant construit le plan de contrôle peut d’abord interpréter un écart comme une mauvaise télémétrie. Un examen distinct de la fiabilité, l’injection de défaillances et l’analyse postérieure aux incidents réduisent ce risque.

Le vaste mandat de Maltz rend cette intégration possible en principe. Les documents publics ne révèlent pas le processus exact de gestion des incidents d’Azure. Le critère pertinent pour la direction consiste à savoir si l’étendue organisationnelle raccourcit le chemin entre le symptôme et la couche responsable, et si les enseignements deviennent des changements d’architecture, de tests et de politique de déploiement au lieu de rester dans le rapport postérieur à l’incident d’une seule équipe de service. Le même principe de reconstruction s’applique au réseau en couches d’Azure.

Un flux client représentatif doit pouvoir être suivi depuis l’intention exprimée par l’API jusqu’à l’état de contrôle, à l’application sur l’hôte ou l’équipement, au chemin de la fabrique et à la dépendance optique. Cet exercice révèle les identifiants et documents manquants avant un incident et vérifie si l’intégration organisationnelle existe réellement au niveau des preuves, plutôt que seulement dans une ligne hiérarchique de direction.

La prochaine architecture sera jugée d’après l’endroit où elle conserve de la souplesse

La succession du logiciel hôte aux SmartNIC FPGA, puis aux DPU et aux chaînes DASH intégrées aux commutateurs montre qu’Azure ne considère pas l’emplacement des fonctions réseau comme fixe. Chaque génération répond à un équilibre différent entre le coût du processeur, la latence, l’énergie, les capacités matérielles et l’évolution des services.

L’infrastructure d’IA intensifie cette pression. Les grandes grappes d’accélérateurs produisent un trafic synchronisé à forte bande passante dont les performances dépendent de la fabrique, du transport et de l’environnement d’exécution collectif. Le réseau doit simultanément prendre en charge les services cloud ordinaires. Le déplacement d’une fonction vers le matériel peut améliorer le débit tout en limitant un nouveau mécanisme de contrôle de congestion ou de sécurité. L’architecture doit conserver suffisamment de souplesse là où les charges de travail évoluent le plus rapidement.

Les preuves ne désignent pas une réponse permanente. Une chaîne plus contrainte peut être efficace et vérifiable. Un DPU programmable peut absorber de nouveaux services, mais consomme de l’énergie et du travail de développement. Le logiciel hôte peut changer rapidement, mais il concurrence les applications. La capacité stratégique ne réside pas dans le choix d’un équipement; elle réside dans la faculté de l’organisation à déplacer la frontière sans modifier la sémantique destinée aux clients ni déstabiliser les opérations.

Cette capacité dépend d’un contrôle et de preuves communs. La télémétrie doit montrer où se produisent les coûts et les retards. La vérification doit tester la nouvelle répartition. SONiC et les autres couches logicielles ont besoin d’interfaces résistant aux variations matérielles. Les plans optiques et de capacité doivent anticiper le trafic rendu possible par la nouvelle conception. Les couches décrites dans le mandat de Maltz forment un seul système de décision, car aucune ne peut être optimisée en toute sécurité de manière isolée.

Le risque non résolu est que l’intégration devienne une concentration. Un fournisseur cloud qui contrôle toute la pile peut innover rapidement, mais les clients et les fournisseurs disposent d’une visibilité réduite sur les dépendances qui en résultent. En interne, une vaste organisation peut coordonner les décisions, mais il peut aussi devenir difficile de remettre une architecture en question une fois que plusieurs couches ont été construites autour d’elle.

La carrière de Maltz offre une manière utile de lire cette tension. VL2 recherchait la liberté de placement, SWAN le contrôle de la capacité, CrystalNet des changements plus sûrs, AccelNet un déport efficace et DASH un nouveau point de consolidation. Chaque système a étendu le contrôle en ajoutant une couche de logiciel et d’organisation. La qualité du résultat dépend de la capacité à maintenir ce contrôle vérifiable et réversible.

La question « qui exploite le réseau d’Azure? » n’a donc pas de réponse tenant en une seule personne. Azure Networking est une organisation d’ingénierie couvrant les services, les systèmes de contrôle, les équipements et la capacité physique. Dave Maltz est le responsable de l’ingénierie publiquement désigné par Microsoft pour Azure Networking et un coauteur documenté de plusieurs systèmes qui ont contribué à façonner le chemin menant à ce modèle. Son importance tient à sa capacité à relier les couches — et à la responsabilité qui accompagne le choix d’un fournisseur cloud de les maîtriser.