Partager via


Notions de base relatives à l’architecture des applications Azure

Une application conçue pour les charges de travail hébergées dans le cloud répond aux exigences métier de la solution et intègre des composants et des fonctionnalités natifs du cloud. Une application cloud bien conçue tient compte de la fiabilité, de la sécurité, du coût, des opérations et des performances. Ces considérations s’alignent sur les exigences métier, les caractéristiques spécifiques de la plateforme d’hébergement cloud et les fonctionnalités fournies par la plateforme.

Vous n’avez pas besoin d’utiliser un style d’application particulier, tel que les microservices, pour concevoir une application pour les charges de travail cloud. Cependant, l’hébergement cloud rend de nombreux modèles de conception d’applications plus accessibles que les solutions d’hébergement qui ne fournissent pas de manière native une sélection diversifiée d’options de plate-forme d’applications et de données, de capacités d’évolutivité, de contrôles de sécurité et d’options de messagerie. Les charges de travail cloud bénéficient d’applications qui sont décomposées en services conçus pour être plus petits et décentralisés. Ces services communiquent via des API ou à l’aide d’une messagerie ou d’une gestion des évènements asynchrone. Les applications se mettent à l'échelle horizontalement en ajoutant de nouvelles instances lorsque la demande augmente.

Les applications qui utilisent des plates-formes d’hébergement d’applications, des fonctionnalités de messagerie et des services décomposés du cloud sont soumises à des préoccupations courantes relatives aux systèmes distribués. Dans ces systèmes, l’état de l’application est distribué et les opérations sont effectuées en parallèle et de manière asynchrone. Les applications doivent être résilientes quand des échecs se produisent. Des acteurs malveillants ciblent sans arrêt les applications. Les déploiements doivent être automatisée et prévisibles. La surveillance et les données de télémétrie sont cruciales pour obtenir des informations sur le système.

Les colonnes suivantes répertorient certaines caractéristiques courantes de la conception sur site et de la conception cloud.

conception locale classique

  • Fonctionnalité et données monolithiques et co-localisées
  • Conçu pour une mise à l'échelle prévisible ou un surapprovisionnement
  • Base de données relationnelle
  • Traitement synchronisé
  • Conçu pour éviter les pannes et mesure le temps moyen entre les pannes (MTBF)
  • Ressources approvisionnées par le biais des fonctions informatiques
  • Serveurs Snowflake et serveurs « pet »

conception cloud classique

  • Fonctionnalités et données décomposées et distribuées
  • Conception pour une mise à l’échelle élastique
  • Persistance polyglotte combinant diverses technologies de stockage
  • Traitement asynchrone
  • Conçu pour résister aux dysfonctionnements et mesure le MTBF
  • Préparé en cas de panne et mesure le temps moyen de réparation
  • Ressources approvisionnées via l’infrastructure as a code selon les besoins
  • Infrastructure immuable et remplaçable

Conception d'applications pour Azure

Les architectes cloud experts dans l’hébergement cloud et qui peuvent prendre des décisions stratégiques doivent concevoir des applications cloud. Azure fournit des ressources pour aider les architectes à développer des applications et guider les équipes de développement dans leur mise en œuvre. Pour obtenir une bonne conception de la charge de travail et des applications, les architectes doivent :

Vous pouvez utiliser Azure pour héberger et réhéberger des applications qui ne sont pas conçues pour le cloud. Vous pouvez ajuster les applications de charge de travail de sorte qu'elles utilisent des fonctionnalités cloud, mais le réhébergement d’une application conçue pour des ressources fixes et une mise à l’échelle n’est pas considéré comme un déploiement natif cloud.

S'aligner sur les normes d'adoption du cloud organisationnelles

Votre application fait partie d’une charge de travail qui doit probablement répondre aux normes organisationnelles et à la gouvernance. Les organisations de toutes tailles et de toute maturité cloud peuvent utiliser Cloud Adoption Framework for Azure pour formaliser leur stratégie d’adoption, leur préparation, leur innovation, leur gestion, leur gouvernance et leurs initiatives de sécurité à l’échelle d’Azure. Une partie de cette approche consiste à standardiser une approche cohérente sur l’ensemble des charges de travail, par exemple en utilisant les zones d’atterrissage Azure. Une zone d’atterrissage Azure fournit une gouvernance à l’échelle de l’organisation et donne aux équipes de charge de travail et aux architectes un accès démocratisé aux ressources pour atteindre les objectifs métier localisés. En tant qu’architecte concevant des applications, il est essentiel que vous compreniez l’environnement dans son ensemble et les attentes en matière d’opérations de charge de travail, telles que les zones d’atterrissage des applications.

La stratégie d’adoption d’Azure de votre organisation ne doit pas affecter le style d'architecture que vous choisissez, mais elle peut restreindre les choix technologiques ou les limites de sécurité.

Suivre le Well-Architected Framework

Vous pouvez évaluer la conception et la mise en œuvre de n’importe quelle charge de travail sous différents angles. Utilisez le Well-Architected Framework pour évaluer et aligner vos décisions sur les principes de conception sur les cinq piliers architecturaux clés suivants :

En suivant ces principes et en évaluant les compromis entre ces piliers architecturaux, vous pouvez produire une conception qui répondra aux exigences métier et qui sera suffisamment durable, facile à entretenir, sécurisée et optimisée en termes de coûts pour s’exécuter dans Azure. Ces décisions doivent éclairer votre choix de style d'architecture et vous aider à affiner vos choix en matière de technologies ou vos limites de sécurité en fonction des besoins spécifiques de votre charge de travail.

Votre équipe, ou votre organisation, peut avoir d’autres principes de conception, tels que la durabilité ou encore l’éthique, et vous pouvez vous appuyer dessus pour évaluer votre charge de travail.

Comprendre les styles d’architecture classiques

Une fois que vous avez compris l’environnement organisationnel dans lequel votre application existera et la base d’une bonne conception d’architecture basée sur le Well-Architected Framework, vous devez décider du type d’architecture à créer. Cela peut être une architecture de microservices, une application multiniveau plus classique ou une solution Big Data. Ces styles d'architecture sont distincts et conçus pour des résultats différents. Lorsque vous évaluez des styles d'architecture, vous devez également sélectionner des modèles de magasin de données pour gérer l’état.

Évaluez les différents styles d’architecture et modèles de magasin de données pour comprendre les avantages et les défis que présente chaque option.

Charges de travail dans le Well-Architected Framework

L’article Charges de travail Well-Architected Framework décrit différents types ou classifications de charges de travail. Vous pouvez trouver des articles sur les charges de travail stratégiques, les charges de travail d’IA et de machine learning ou les charges de travail de logiciel en tant que service. Ces articles ciblés sur certaines charges de travail appliquent les cinq piliers fondamentaux du Well-Architected Framework au domaine concerné. Si votre application fait partie d’une charge de travail qui s’aligne sur l’un de ces modèles documentés, consultez les instructions respectives pour vous aider à aborder votre conception en suivant un ensemble de principes et de recommandations de conception spécifiques à la charge de travail dans des domaines de conception courants, tels que la plate-forme d’application, la plate-forme de données et la mise en réseau. Certains types de charge de travail peuvent tirer parti de la sélection d’un style architectural spécifique ou d’un modèle de magasin de données.

Meilleures pratiques

Pour plus d’informations sur les diverses considérations de conception, notamment la conception d’API, la mise à l’échelle automatique, le partitionnement des données ou encore la mise en cache, consultez Bonnes pratiques dans les applications cloud. Passez-les en revue et appliquez les bonnes pratiques adaptées à votre application.

Utiliser des modèles de conception pour résoudre les problèmes courants et introduire des compromis stratégiques

Votre application a des exigences métier, des objectifs et des mesures de réussite spécifiques. Vous devez décomposer ces exigences fonctionnelles et non fonctionnelles en activités distinctes qui fonctionnent ensemble pour obtenir une solution qui répond à vos attentes ainsi qu'à celles de vos clients. Ces activités suivent généralement les modèles établis par l’industrie du logiciel. Les modèles de conception de logiciels sont des approches nommées et reproductibles que vous pouvez appliquer au traitement ou au stockage de données. Il est prouvé que ces modèles résolvent des problèmes spécifiques avec des compromis connus.

Le catalogue de modèles de conception cloud dans Azure résout des défis spécifiques dans les systèmes distribués. Pour les charges de travail IA qui incluent plusieurs agents autonomes, consultez les modèles d’orchestration des agents IA. Il comprend des approches de coordination spécialisées qui complètent les modèles de conception traditionnels en répondant aux défis uniques liés à l’orchestration de composants intelligents et autonomes.

Faire des choix éclairés en matière de technologies

Une fois que vous avez déterminé le type d’architecture que vous souhaitez créer et les modèles de conception que vous prévoyez d’utiliser, vous pouvez choisir les principaux composants technologiques de l’architecture. Les choix suivants en matière de technologies sont essentiels :

Vous ferez probablement d’autres choix technologiques en cours de route, mais le calcul, les données, la messagerie et l’IA sont au cœur de la plupart des applications cloud et déterminent de nombreux aspects de votre conception.

Évaluer les architectures de référence

Le Centre des architectures Azure héberge des articles contenant des idées de solutions, des exemples de charges de travail et des architectures de référence. Ces articles répertorient généralement les composants et considérations courants qui s’alignent sur le Well-Architected Framework. Certains de ces articles incluent une solution déployable hébergée sur GitHub. Bien qu’il soit peu probable que l’un de ces scénarios soit exactement ce que vous construisez, ils constituent un bon point de départ. Vous pouvez adapter les conseils à vos besoins spécifiques.

Parcourez le catalogue d’architectures dans le Centre des architectures Azure.

Passer en revue les guides spécifiques au service

Une fois que vous avez sélectionné la technologie de base et consulté les architectures de référence, consultez la documentation et les conseils spécifiques aux services de votre architecture. Consultez les ressources suivantes pour obtenir des conseils spécifiques au service :

  • Guides des services Well-Architected Framework : le Well-Architected Framework propose des articles sur de nombreux services Azure. Les articles appliquent les cinq piliers de l’architecture à chaque service.

  • Guides de fiabilité Azure : le hub de fiabilité Azure contient des articles détaillés qui abordent spécifiquement les caractéristiques de fiabilité de nombreux services Azure. Ces articles documentent certains des sujets de fiabilité les plus critiques, tels que la prise en charge des zones de disponibilité et le comportement attendu lors de différents types de pannes.

En provenance d’un autre cloud ?

Si vous savez comment concevoir des applications chez un autre fournisseur de cloud, la plupart des principes fondamentaux s’appliquent. Par exemple, les styles d’architecture et les modèles de conception cloud sont conceptuellement indépendants du cloud. Pour plus d’informations, consultez les articles suivants du guide de mappage et d’architecture de service :

Étape suivante