Styles d’architecture

Un style d’architecture est une famille d’architectures qui partagent des caractéristiques spécifiques. Par exemple, le niveau N est un style d’architecture courant. Plus récemment, les architectures de microservice commencent à gagner en faveur. Les styles d’architecture ne nécessitent pas l’utilisation de technologies spécifiques, mais certaines technologies sont mieux adaptées à certaines architectures. Par exemple, les conteneurs sont bien adaptés aux microservices.

Nous avons identifié un ensemble de styles d’architecture couramment trouvés dans les applications cloud. L’article pour chaque style comprend les composants suivants :

• Description et diagramme logique du style
• Recommandations pour quand choisir ce style
• Avantages, défis et meilleures pratiques
• Déploiement recommandé qui utilise des services Azure pertinents

Une visite guidée rapide des styles

Cette section présente rapidement les styles d’architecture que nous avons identifiés, ainsi que quelques considérations générales pour leur utilisation. Cette liste n’est pas exhaustive. Pour plus d’informations, consultez les articles liés.

Niveau N

La couche N est une architecture traditionnelle pour les applications d’entreprise qui divise une application en couches logiques et niveaux physiques. Chaque couche a une responsabilité spécifique et les couches gèrent les dépendances en appelant uniquement les couches sous elles. Les couches classiques incluent la présentation, la logique métier et l’accès aux données.

Les architectures multiniveau conviennent parfaitement à la migration d’applications existantes qui utilisent déjà une architecture en couches. Cette approche nécessite des modifications minimales lorsque vous passez à Azure et prend en charge des environnements mixtes avec des composants locaux et cloud. Toutefois, la superposition horizontale peut compliquer l’introduction de modifications sans affecter plusieurs parties de l’application, ce qui limite l’agilité pour les mises à jour fréquentes.

Web-File d’attente-Worker

Web-Queue-Worker est une architecture qui se compose d’un serveur frontal web, d’une file d’attente de messages et d’un worker back-end. Le serveur frontal web gère les requêtes HTTP et les interactions avec l'utilisateur, tandis que l'agent effectue des tâches gourmandes en ressources, des workflows de longue durée ou des opérations par lots. La communication entre l'interface utilisateur et le processus de travail se produit via une file d’attente de messages asynchrone.

Cette architecture est idéale pour les applications avec des domaines relativement simples qui ont des exigences de traitement gourmandes en ressources. Il est facile de comprendre et de déployer avec des services Azure gérés comme App Service et Azure Functions. Vous pouvez mettre à l’échelle le serveur frontal et le processus de travail indépendamment pour offrir une flexibilité dans l’allocation des ressources. Mais sans conception minutieuse, les deux composants peuvent devenir volumineux et monolithiques.

Microservices

L’architecture des microservices décompose les applications en une collection de petits services autonomes. Chaque service implémente une seule fonctionnalité métier dans un contexte limité et est autonome avec son propre stockage de données. Les services communiquent via des API bien définies et peuvent être développés, déployés et mis à l’échelle indépendamment.

Les microservices permettent aux équipes de travailler de manière autonome et de prendre en charge les mises à jour fréquentes avec une vitesse de mise en production plus élevée. Cette architecture est bien adaptée aux domaines complexes qui nécessitent des changements fréquents et une innovation. Toutefois, il introduit une complexité significative dans les domaines tels que la découverte de services, la cohérence des données et la gestion du système distribué. La réussite nécessite un développement mature et des pratiques DevOps, ce qui le rend plus adapté aux organisations qui ont des fonctionnalités techniques avancées.

Architecture basée sur les événements

Les architectures pilotées par les événements utilisent un modèle d’abonnement de publication où les producteurs d’événements génèrent des flux d’événements et les consommateurs d’événements répondent à ces événements en quasi-temps réel. Les producteurs et les consommateurs sont découplés les uns des autres, la communication se produisant par le biais de canaux d’événements ou de répartiteurs. Cette architecture prend en charge le traitement d’événements simple et l’analyse complexe des modèles d’événements.

Les architectures pilotées par les événements excellent dans les scénarios qui nécessitent un traitement en temps réel avec une latence minimale. Voici quelques exemples de solutions IoT, de systèmes de trading financiers ou d’applications qui doivent traiter des volumes élevés de données de streaming. Les architectures pilotées par les événements offrent une excellente scalabilité et une isolation des pannes, mais présentent des défis autour de la livraison garantie, de l’ordre des événements et de la cohérence éventuelle entre les composants distribués.

Big Data

Les architectures Big Data gèrent l’ingestion, le traitement et l’analyse des données trop volumineuses ou complexes pour les systèmes de base de données traditionnels. Ces architectures incluent généralement des composants pour le stockage des données (comme les lacs de données), le traitement par lots pour l’analyse historique, le traitement de flux pour les insights en temps réel et les magasins de données analytiques pour la création de rapports et la visualisation.

Les architectures Big Data sont essentielles pour les organisations qui doivent extraire des insights à partir de jeux de données massifs, prendre en charge l’analytique prédictive à l’aide du Machine Learning ou traiter des données de streaming en temps réel à partir d’appareils IoT. Les implémentations modernes utilisent souvent des services managés comme Microsoft Fabric pour simplifier la création et la maintenance de solutions Big Data.

Big Compute

Les architectures de calcul volumineuses prennent en charge les charges de travail à grande échelle qui nécessitent des centaines ou des milliers de cœurs pour des opérations nécessitant beaucoup de ressources de calcul. Le travail peut être divisé en tâches discrètes qui s'exécutent simultanément sur de nombreux cœurs, chaque tâche effectuant sa prise d'entrée, son traitement, et sa production de sortie. Les tâches peuvent être indépendantes (embarrassantement parallèles) ou étroitement couplées nécessitant une communication haute vitesse.

Le big compute est essentiel pour les simulations, la modélisation des risques financiers, l’informatique scientifique, l’analyse du stress technique et le rendu 3D. Azure fournit des options telles qu’Azure Batch pour les charges de travail de calcul volumineuses gérées ou HPC Pack pour une gestion de cluster plus traditionnelle. Ces architectures peuvent augmenter la capacité de manière élastique à la demande et s'étendre à des milliers de cœurs si nécessaire.

Styles d’architecture en tant que contraintes

Un style d’architecture place des contraintes sur la conception, y compris l’ensemble d’éléments qui peuvent apparaître et les relations autorisées entre ces éléments. Les contraintes guident la « forme » d’une architecture en limitant l’univers des choix. Lorsqu’une architecture est conforme aux contraintes d’un style particulier, certaines propriétés souhaitables émergent.

Par exemple, les contraintes dans les microservices sont les suivantes :

• Un service représente une responsabilité unique.
• Chaque service est indépendant des autres.
• Les données sont privées au service qui le possède. Les services ne partagent pas de données.

Lorsque vous respectez ces contraintes, vous bénéficiez d’un système qui vous permet d’effectuer les actions suivantes :

• Déployez des services indépendamment.
• Isoler les pannes.
• Envoyer des mises à jour plus fréquentes.
• Introduisez plus facilement de nouvelles technologies dans l’application.

Chaque style d’architecture a ses propres compromis. Avant de choisir un style architectural, il est essentiel de comprendre les principes et contraintes sous-jacents. Sans cette compréhension, vous risquez de créer une conception qui se conforme superficiellement au style sans réaliser ses avantages complets. Concentrez-vous davantage sur la raison pour laquelle vous sélectionnez un style spécifique que sur la façon de l’implémenter. Soyez pratique. Parfois, il est préférable de détendre une contrainte que de chercher la pureté architecturale.

Dans l’idéal, le choix du style architectural doit être effectué avec des commentaires des parties prenantes de la charge de travail informées. L’équipe de charge de travail doit commencer par identifier la nature du problème qu’elle résout. Ils doivent ensuite définir les principaux facteurs métier et les caractéristiques d’architecture correspondantes, également appelées exigences non fonctionnelles, et les hiérarchiser. Par exemple, si le temps de commercialisation est critique, l’équipe peut hiérarchiser la maintenance, la testabilité et la fiabilité pour permettre un déploiement rapide. Si l’équipe a des contraintes budgétaires serrées, la faisabilité et la simplicité peuvent être prioritaires. La sélection et la prise en charge d’un style architectural ne sont pas une tâche ponctuelle. Elle nécessite une mesure, une validation et un affinement continus. Étant donné que la modification de la direction architecturale peut être coûteuse ultérieurement, il est souvent utile d’investir davantage d’efforts pour soutenir l’efficacité à long terme et réduire les risques.

Le tableau suivant résume la façon dont chaque style gère les dépendances et les types de domaine les mieux adaptés à chaque style.

Prendre en compte les défis et les avantages

Les contraintes créent également des défis, il est donc important de comprendre les compromis lorsque vous adoptez l’un de ces styles. Déterminez si les avantages du style d’architecture l’emportent sur les défis, pour ce sous-domaine et ce contexte limité.

Tenez compte des types de défis suivants lorsque vous sélectionnez un style d’architecture :

• Complexité: La complexité de l’architecture doit correspondre au domaine. Si c’est trop simpliste, cela peut entraîner une grosse boule de boue, où les dépendances ne sont pas bien gérées et la structure se décompose.

• Messagerie asynchrone et cohérence éventuelle : La messagerie asynchrone est utilisée pour dissocier les services et améliorer la fiabilité, car les messages peuvent être retentés. Il améliore également l’extensibilité. Toutefois, la messagerie asynchrone crée également des difficultés pour gérer la cohérence éventuelle et la possibilité de dupliquer les messages.

• Communication interservice : La décomposition d’une application en services distincts peut augmenter la surcharge de communication. Dans les architectures de microservices, cette surcharge entraîne souvent des problèmes de latence ou une congestion du réseau.

• Gérabilité: La gestion de l’application inclut des tâches telles que la surveillance, le déploiement de mises à jour et la maintenance de l’intégrité opérationnelle.

Ressources associées

• Dix principes de conception pour les applications Azure

Étapes suivantes

• Créer des applications sur Microsoft Cloud
• Meilleures pratiques dans les applications cloud
• modèles de conception cloud
• Tests de performances et antimodèles pour les applications cloud
• Définir l’architecture de solutions multilocataires sur Azure
• Architecture de charge de travail critique sur Azure
• Architecture pour les start-ups