Styles d’architecture

Un style d’architecture est une famille d’architectures qui partagent certaines caractéristiques. Par exemple, multiniveau est un style d’architecture courant. Plus récemment, les architectures de microservices ont commencé à obtenir une place de choix. Les styles d’architecture ne nécessitent pas l’utilisation de technologies particulières, mais certaines technologies sont bien adaptées pour certaines architectures. Par exemple, les conteneurs sont naturellement adaptés aux microservices.

Nous avons identifié un ensemble de styles d’architecture qui sont couramment utilisés dans les applications cloud. L’article inclut pour chaque style :

• Une description et un diagramme logique du style.
• Des recommandations concernant le moment approprié pour choisir le style.
• Les avantages, les défis et les meilleures pratiques.
• Un déploiement recommandé à l’aide des services Azure appropriés.

Une présentation rapide des styles.

Cette section fournit une présentation rapide des styles d’architecture que nous avons identifiés, ainsi que certaines considérations de haut niveau pour leur utilisation. Veuillez noter que cette liste n'est pas exhaustive. Obtenez plus de détails dans les rubriques associées.

Multiniveau

Le multiniveau est une architecture classique pour les applications d’entreprise. Les dépendances sont gérées en divisant l’application en couches qui exécutent des fonctions logiques, telles que la présentation, la logique métier et l’accès aux données. Une couche ne peut appeler que des couches inférieures. Toutefois, cette superposition horizontale peut être une responsabilité. Il peut être difficile d’introduire des modifications dans une partie de l’application sans toucher le reste de l’application. Ainsi, les mises à jour fréquentes sont un défi, elles limitent la rapidité avec laquelle de nouvelles fonctionnalités peuvent être ajoutées.

L’architecture multiniveau convient parfaitement pour la migration d’applications existantes qui utilisent déjà une architecture en couches. Pour cette raison, l’architecture multiniveau est le plus souvent vue dans les solutions de type infrastructure as a service (IaaS), ou comme une application qui utilise une combinaison de IaaS et de services gérés.

Web-File d’attente-Worker

Pour une solution purement PaaS, envisagez une architecture Web-File d’attente-Worker . Dans ce style, l’application possède un serveur web frontal qui gère les requêtes HTTP et un Worker principal qui exécute les tâches sollicitant beaucoup le processeur ou les opérations longues. Le serveur frontal communique avec le Worker via une file d’attente de messages asynchrones.

L’architecture Web-File d’attente-Worker est adaptée aux domaines relativement simples avec certaines tâches gourmandes en ressources. Comme pour l’architecture multiniveau, cette architecture est facile à comprendre. L’utilisation de services gérés simplifie le déploiement et les opérations. Mais avec des domaines complexes, il peut être difficile de gérer les dépendances. Le serveur frontal et le Worker peuvent facilement devenir des composants monolithiques volumineux, difficiles à gérer et à mettre à jour. Comme avec l’architecture multicouche, cela peut réduire la fréquence des mises à jour et limiter l’innovation.

Microservices

Si votre application a un domaine plus complexe, envisagez de passer à une architecture de microservices . Une application de microservices est composée de nombreux services indépendants et de petite taille. Chaque service implémente une fonctionnalité unique. Les services sont faiblement couplés et communiquent via des contrats d’API.

Chaque service peut être généré par une équipe de développement petite et ciblée. Les services individuels peuvent être déployés sans beaucoup de coordination entre les équipes, ce qui permet des mises à jour fréquentes. Une architecture de microservices est plus complexe à créer et à gérer que les architectures multiniveau ou Web-File d’attente-Worker. Elle nécessite un développement mature et une culture DevOps. Mais bien mis en place, ce style peut libérer plus de rapidité, accélérer l’innovation et permettre une architecture plus résiliente.

Architecture basée sur les événements

Les architectures basées sur les événements utilisent un modèle de publication-abonnement (pub-sub), où les producteurs publient des événements et les consommateurs s’y abonnent. Les producteurs sont indépendants des consommateurs et les consommateurs sont indépendants les uns des autres.

Envisagez une architecture basée sur les événements pour les applications qui reçoivent et traitent un gros volume de données avec une latence très faible, telles que les solutions IoT. Le style est également utile lorsque différents sous-systèmes doivent effectuer différents types de traitement sur les mêmes données d’événement.

Big Data et Big Compute

Big Data et Big Compute sont des styles d’architecture spécialisée pour les charges de travail qui correspondent à certains profils spécifiques. Le Big Data divise un très grand jeu de données en plusieurs blocs en exécutant un traitement parallèle sur l’ensemble du jeu de données à des fins d’analyse et de création de rapports. Big compute, également appelé High-Performance Computing, calcul haute performance (HPC), effectue des calculs parallèles sur un grand nombre (des milliers) de cœurs. Les domaines incluent des simulations, des modélisations et un rendu 3D.

Les styles d’architecture en tant que contraintes

Un style d’architecture implique des contraintes de conception, y compris l’ensemble d’éléments qui peuvent s’afficher et les relations autorisées entre ces éléments. Les contraintes encadrent la « forme » d’une architecture en limitant les choix possibles. Lorsqu’une architecture se conforme aux limites d’un style particulier, certaines propriétés souhaitables émergent.

Les contraintes de microservices incluent, par exemple :

• Un service représente une seule responsabilité.
• Chaque service est indépendant des autres.
• Les données sont privées et accessibles uniquement au service auquel elles appartiennent. Les services ne partagent pas de données.

En adhérant à ces contraintes, ce qui apparaît est un système où les services peuvent être déployés indépendamment, les erreurs sont isolées, les mises à jour fréquentes sont possibles et il est facile d’introduire de nouvelles technologies dans l’application.

Chaque style d'architecture a ses propres compromis. Par conséquent, avant de choisir un style d'architecture, assurez-vous que vous comprenez les principes et les contraintes sous-jacents de ce style. Dans le cas contraire, vous pouvez vous retrouver avec une conception qui est conforme au style à un niveau superficiel, mais qui n’atteint pas tout le potentiel de ce style. Vous devez vous intéresser davantage aux raisons pour lesquelles vous choisissez un style d'architecture donné qu’à la manière de le mettre en œuvre. Il est également important d’être pragmatique. Il est parfois préférable d’assouplir une contrainte, plutôt que d’insister sur la pureté de l’architecture.

Le choix d'un style d'architecture approprié devrait se faire idéalement avec un consensus des parties prenantes informées de la charge de travail. L'équipe de la charge de travail doit tout d'abord identifier la nature du problème qu'elle tente de résoudre. Ils doivent ensuite identifier les moteurs de l'activité et les caractéristiques correspondantes de l'architecture (également connues sous le nom d'exigences non fonctionnelles), puis les classer par ordre de priorité. Par exemple, s'ils ont besoin d'un délai de mise sur le marché plus court, ils peuvent donner la priorité à la maintenabilité, à la testabilité et à la fiabilité par des capacités de déploiement rapide. De même, si l'équipe responsable de la charge de travail dispose d'un budget limité, elle peut donner la priorité à la faisabilité et à la simplicité. Le choix et le maintien d'un style architectural n'est pas une activité ponctuelle, mais une approche continue : l'architecture doit être continuellement mesurée, validée et affinée au fil du temps. Le changement de style architectural entraîne généralement des coûts importants, de sorte qu'un effort supplémentaire au départ peut se justifier pour l'efficacité de l'équipe à long terme et l'atténuation des risques.

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

Prenez en compte les avantages et les défis

Les contraintes créent également des défis, il est donc important de comprendre les inconvénients lors de l’adoption d’un de ces styles. Les avantages peuvent l’emporter sur les défis liés au style architecture, pour ce sous-domaine et le contexte limité.

Voici quelques types de problèmes à prendre en compte lors de la sélection d’un style d’architecture :

• Complexité : La complexité de l’architecture est-elle justifiée pour votre domaine ? À l’inverse, le style est-il trop simpliste pour votre domaine ? Dans ce cas, vous risquez de vous retrouver avec une « grande boule de boue » parce que l’architecture ne vous aide pas à gérer correctement les dépendances.

• Messagerie asynchrone et cohérence éventuelle. La messagerie asynchrone peut être utilisée pour séparer des services et améliorer la fiabilité (étant donné que les messages peuvent être tentés à nouveau) et l’extensibilité. Toutefois, cela crée également des difficultés pour gérer la cohérence finale et une duplication possible des messages.

• Communication interservice Lorsque vous décomposez une application en services distincts, il est possible que la communication entre services provoque une latence inacceptable ou crée une congestion du réseau (par exemple, dans une architecture microservices).

• Facilité de gestion. Est-il difficile de gérer l’application, analyser, déployer des mises à jour et ainsi de suite ?

Ressources associées

• Dix principes de conception pour les applications Azure
• Créer des applications sur Microsoft Cloud
• Meilleures pratiques dans les applications cloud
• Modèles de conception cloud
• Tests et antimodèles de performance pour les applications cloud
• Définir l’architecture de solutions multilocataires sur Azure
• Architecture de charges de travail critiques sur Azure
• Architecture pour les démarrages