Construire une architecture Azure qui résiste au monde réel — avec Mike Martin [MVP]

L'architecture Azure semble simple quand tout fonctionne. Le véritable test commence lorsque les dépendances tombent en panne, que des régions deviennent indisponibles, que le trafic explose, que les hypothèses se révèlent fausses, que les exigences évoluent et que quelqu'un finit par poser la question embarrassante : pourquoi avons-nous conçu les choses de cette façon ?
Dans cet épisode de M365.FM, Mirko Peters s'entretient avec Mike Martin [MVP] sur ce à quoi ressemble une architecture Azure lorsqu'elle doit survivre aux conditions réelles de production plutôt que simplement bien paraître sur un schéma.Mike possède des décennies d'expérience en développement, infrastructure, architecture, direction, coaching, formation et Microsoft Azure. L'une de ses observations les plus marquantes est que beaucoup des problèmes auxquels les architectes sont confrontés aujourd'hui ne sont pas vraiment nouveaux. Le DNS tombe toujours en panne, les dépendances IP comptent toujours, les coûts deviennent toujours un problème, les intégrations échouent toujours, et les dépendances disparaissent toujours au pire moment.Ce qui a changé, c'est le niveau de complexité que nous construisons autour de ces problèmes.

DE VISUAL BASIC À L'ARCHITECTURE AZURE MODERNE
Mike revient sur près de trois décennies dans l'informatique, en commençant comme développeur Visual Basic dans les années 1990, puis en passant par les systèmes distribués, la mise en réseau, les logiciels d'entreprise, l'infrastructure et finalement Azure.Son observation clé est simple : le secteur continue de résoudre les mêmes problèmes fondamentaux, mais les architectures qui les entourent sont devenues beaucoup plus complexes.Les systèmes modernes sont passés des applications client-serveur aux architectures distribuées, aux plateformes cloud, aux conteneurs, aux microservices, à Kubernetes, aux environnements hybrides et désormais au développement assisté par l'IA.Cela ouvre d'énormes possibilités, mais crée aussi un nouveau risque : la sur-ingénierie.Mike soutient que de nombreuses équipes compliquent inutilement des problèmes simples. Une bonne architecture ne consiste pas souvent à ajouter davantage de technologies, mais à savoir ce qu'il ne faut pas ajouter.

QUE FAIT RÉELLEMENT UN ARCHITECTE AZURE ?
Pour Mike, l'architecture ne consiste pas à choisir le plus grand nombre de services Azure ni à produire un schéma impressionnant.Il s'agit de comprendre quels composants doivent aller ensemble, lesquels doivent être évités, lesquels sont nécessaires, et comment construire une solution maintenable, évolutive, sécurisée et résiliente.L'architecture dépasse largement le calcul.

• Identité
• Réseau
• Flux de données
• Sécurité
• Supervision
• Intégration
• Dépendances
• Évolutivité
• Exploitation
• Reprise
• Déploiement
• Coût

Mike remet également en question l'idée que cloud-native signifie automatiquement Kubernetes ou conteneurs. Azure propose de nombreux services managés et natifs capables de résoudre des problèmes sans introduire de charge opérationnelle inutile.Le rôle de l'architecte est de comprendre la solution dans son ensemble et de choisir l'architecture la plus simple qui satisfait néanmoins les exigences réelles.

COMMENCER PAR LES EXIGENCES MÉTIER, PAS PAR LES SERVICES AZURE
L'une des leçons les plus importantes de cet épisode est simple : ne commencez pas par la technologie.Avant de choisir entre Azure Kubernetes Service, App Service, Azure Functions, conteneurs, Service Bus ou une autre plateforme, les équipes doivent d'abord comprendre ce que la solution doit réellement faire.Questions à se poser :

• S'agit-il d'un usage interne ou destiné aux clients ?
• Combien d'utilisateurs en dépendront ?
• Doit-elle évoluer à l'échelle mondiale ?
• Combien de temps peut-elle être indisponible ?
• Quelle quantité de données l'entreprise peut-elle se permettre de perdre ?
• Quelles exigences de conformité s'appliquent ?
• Que se passe-t-il si l'application disparaît pendant plusieurs heures ?
• Qui est affecté ?
• Quel niveau de support opérationnel est requis ?

Ces questions mènent directement à des concepts comme les SLA, SLO, RTO et RPO. Elles déterminent aussi si l'architecture doit être mono-région, multi-régions, active-active, active-passive ou beaucoup plus simple.

RTO ET RPO SANS LE JARGON
Le RTO et le RPO sont souvent présentés comme des acronymes techniques, mais leur signification réelle est orientée métier.

• RTO — Recovery Time Objective : en combien de temps le système doit-il être rétabli après une panne ?
• RPO — Recovery Point Objective : quelle perte de données est acceptable ?

Un système utilisé pour une supervision non critique peut tolérer plusieurs heures d'indisponibilité ou de perte de données. Un système au service des premiers secours, des opérations financières, du commerce ou d'infrastructures critiques peut exiger une reprise en quelques minutes.Le point important est que ces chiffres ne doivent pas être inventés par l'architecte. Ils doivent provenir de l'impact métier réel d'une panne.Une fois ces exigences comprises, elles peuvent être traduites en décisions de conception techniques.

LA RÉSILIENCE N'EST PAS LA MÊME CHOSE QUE LA HAUTE DISPONIBILITÉ
Mike utilise une analogie simple pour expliquer la différence entre disponibilité et résilience.Un système hautement disponible peut disposer d'un autre composant prêt à prendre le relais lorsque le principal tombe en panne.Un système résilient est conçu pour absorber les problèmes, continuer à fonctionner, se rétablir avec souplesse et revenir à la normale sans s'effondrer complètement.Cette distinction est importante.Une application peut être techniquement disponible tout en offrant une mauvaise expérience.Elle peut être :

• Lente
• Limitée (throttling)
• Partiellement indisponible
• Dépendante d'un backend défaillant
• Affectée par un problème d'intégration
• Sous pression régionale

La véritable résilience exige donc davantage que la disponibilité.Elle nécessite une architecture capable de supporter la charge, les erreurs applicatives, les pannes partielles, les incidents régionaux, les dépendances défaillantes, les incidents opérationnels et la reprise une fois l'incident passé.

AZURE NE REND PAS VOTRE APPLICATION RÉSILIENTE AUTOMATIQUEMENT
Une hypothèse dangereuse consiste à croire que, parce qu'Azure est lui-même hautement disponible, toute application exécutée sur Azure hérite automatiquement de cette résilience.Ce n'est pas le cas.Microsoft fournit les services et les capacités qui rendent possibles les architectures résilientes.Les clients doivent toujours concevoir cette résilience.C'est là que les modèles d'architecture prennent toute leur importance :

• Circuit breakers (disjoncteurs)
• Couplage faible
• Traitement asynchrone
• Mise à l'échelle indépendante
• Plusieurs zones de disponibilité
• Plusieurs régions
• Mécanismes de basculement
• Supervision
• Infrastructure as Code
• Procédures de reprise testées

Microsoft fournit les briques de base. L'architecture détermine si ces briques créent réellement un système résilient.

POURQUOI LA CONCEPTION ASYNCHRONE COMPTE
L'un des exemples les plus forts de l'épisode concerne les systèmes qui subissent des pics de trafic prévisibles, comme les portails fiscaux gouvernementaux.Un problème de conception courant survient lorsque chaque action dépend d'une opération backend synchrone.L'utilisateur clique sur un bouton. Le frontend attend le backend. Le backend attend un autre service. Une autre dépendance ralentit. Finalement, toute l'expérience utilisateur est affectée.Mike explique pourquoi les systèmes faiblement couplés sont souvent plus résilients. Au lieu d'obliger le frontend à attendre chaque opération backend, les applications peuvent placer le travail dans des files d'attente ou des systèmes événementiels et laisser les composants traiter les tâches de manière indépendante.Cela apporte plusieurs avantages :

• Les différents composants peuvent évoluer indépendamment
• Un service peut tomber en panne sans entraîner toute la plateforme
• Les backends peuvent traiter le travail de manière asynchrone
• Les pics de trafic deviennent plus faciles à absorber
• Les composants orientés utilisateur dépendent moins du timing du backend
• Les pannes deviennent plus faciles à isoler

LE MYTHE DE LA DISPONIBILITÉ À 100 %
Un autre sujet majeur de la discussion est l'obsession de la disponibilité à 100 %.Mike est très clair : une disponibilité de 100 % n'est pas un objectif d'architecture réaliste.Une solution est généralement composée de plusieurs services. Chaque service possède son propre SLA. Une fois plusieurs dépendances combinées, la