Recommandations pour la conception pour la simplicité et l’efficacité
S’applique à cette recommandation de liste de contrôle de fiabilité d’Azure Well-Architected Framework :
| RE :01 | Concevez votre charge de travail pour qu’elle s’aligne sur vos objectifs métier et évitez toute complexité ou surcharge inutile. Utilisez une approche pratique et équilibrée pour prendre des décisions de conception qui fournissent les résultats souhaités. Contiennez votre conception pour réduire les inefficacités et les problèmes potentiels. |
|---|
Ce guide décrit les recommandations pour réduire la complexité et la surcharge inutiles afin de simplifier et d’optimiser vos charges de travail. Choisissez les meilleurs composants pour effectuer les tâches de charge de travail nécessaires pour optimiser la fiabilité de votre charge de travail. Pour réduire vos charges de développement et de gestion, tirez parti de l’efficacité offerte par les services fournis par la plateforme. Cette conception vous aide à créer une architecture de charge de travail résiliente, reproductible, évolutive et gérable.
Définitions
| Terme | Définition |
|---|---|
| Charge de travail | Fonctionnalité discrète ou tâche informatique que vous pouvez séparer logiquement d’autres tâches. |
Stratégies de conception
Une clé de conception pour la fiabilité est de garder les choses simples et efficaces. Concentrez la conception de votre charge de travail sur la satisfaction des besoins de l'entreprise afin de réduire le risque de complexité inutile ou de frais généraux excessifs. Tenez compte des recommandations de cet article pour vous aider à prendre des décisions sur votre conception afin de créer une charge de travail maigre, efficace et fiable. Des charges de travail différentes peuvent avoir des exigences différentes concernant la disponibilité, la scalabilité, la cohérence des données et la récupération d’urgence.
Vous devez justifier chaque décision de conception avec une exigence métier. Ce principe de conception peut sembler évident, mais il est essentiel pour la conception de la charge de travail. Votre application prend-elle en charge des millions d’utilisateurs, ou quelques milliers ? Existe-t-il de grandes rafales de trafic ou une charge de travail stable ? Quel niveau de panne d’application est acceptable ? Les exigences métier déterminent ces considérations de conception.
Compromis : une solution complexe peut offrir plus de fonctionnalités et de flexibilité, mais elle peut affecter la fiabilité de la charge de travail, car elle nécessite davantage de coordination, de communication et de gestion des composants. Sinon, une solution plus simple peut ne pas répondre entièrement aux attentes des utilisateurs, ou elle peut avoir un effet négatif sur l’extensibilité et l’extensibilité à mesure que la charge de travail évolue.
Collaborer avec les parties prenantes sur des exercices de conception
Collaborez avec les parties prenantes pour :
Définissez et affectez un niveau de criticité aux flux utilisateur et aux flux système de votre charge de travail. Concentrez votre conception sur les flux critiques pour vous aider à déterminer les composants requis et la meilleure approche pour atteindre le niveau de résilience requis.
Définissez des exigences fonctionnelles et non fonctionnelles. Tenez compte des exigences fonctionnelles pour déterminer si une application effectue une tâche. Considérez les exigences non fonctionnelles pour déterminer la façon dont l’application effectue une tâche. Vérifiez que vous comprenez les exigences non fonctionnelles telles que l’extensibilité, la disponibilité et la latence. Ces exigences influencent les décisions de conception et les choix de technologie.
Décomposer les charges de travail en composants. Hiérarchiser la simplicité, l’efficacité et la fiabilité dans votre conception. Déterminez les composants dont vous avez besoin pour prendre en charge vos flux. Certains composants prennent en charge plusieurs flux. Identifiez les défis qu’un composant résout conceptuellement et envisagez de supprimer un composant de flux individuels pour simplifier la conception globale tout en offrant une fonctionnalité complète. Pour plus d’informations, consultez Recommandations pour effectuer une analyse du mode d’échec.
Utilisez l’analyse du mode d’échec pour identifier les points uniques de défaillance et les risques potentiels. Déterminez si vous devez tenir compte des situations peu probables, par exemple une zone géographique qui subit une catastrophe naturelle majeure qui affecte toutes les zones de disponibilité de la région. Il est coûteux et implique des compromis importants pour atténuer ces risques rares. Comprenez clairement la tolérance de votre entreprise au risque. Pour plus d’informations, consultez Recommandations pour effectuer une analyse du mode d’échec.
Définissez des cibles de disponibilité et de récupération pour vos flux afin d’informer l’architecture de votre charge de travail. Les métriques métier incluent les objectifs de niveau de service (SLA), les contrats de niveau de service (SLA), le temps moyen de récupération (MTTR), le temps moyen entre l’échec (MTBF), les objectifs de temps de récupération (RTO) et les objectifs de point de récupération (RPO). Définissez des valeurs cibles pour ces métriques. Cet exercice peut nécessiter une compromission et une compréhension mutuelle entre les équipes technologiques et commerciales pour s’assurer que les objectifs de chaque équipe répondent aux objectifs métier et sont réalistes. Pour plus d’informations, consultez Recommandations pour définir des objectifs de fiabilité.
Favoriser les choix de conception plus simples
Vous pouvez effectuer les recommandations suivantes sans engagement des parties prenantes :
Efforcez-vous de simplicité et de clarté dans votre conception. Utilisez le niveau approprié d’abstraction et de granularité pour vos composants et services. Évitez la sur-ingénierie ou la sous-ingénierie de votre solution. Par exemple, si vous décomposez votre code en plusieurs petites fonctions, il est difficile de comprendre, tester et gérer.
Reconnaissez que toutes les applications réussies changent au fil du temps, qu’elles corrigent les bogues, implémentent de nouvelles fonctionnalités ou technologies, ou rendent les systèmes existants plus évolutifs et résilients.
Utilisez les options PaaS (Platform as a Service) au lieu d’infrastructure as a service (IaaS) si possible. L’approche IaaS équivaut à disposer d’un carton rempli de pièces. Vous pouvez construire tout ce que vous voulez, mais vous devez tout assembler vous-même. Les options PaaS sont plus faciles à configurer et à administrer. Vous n’avez pas besoin de configurer des machines virtuelles ou des réseaux virtuels. Vous n’avez pas non plus besoin d’effectuer des tâches de maintenance, telles que l’installation de correctifs et de mises à jour.
Utilisez la messagerie asynchrone pour dissocier le producteur de messages du consommateur.
Extrayez l’infrastructure de la logique du domaine. Assurez-vous que la logique de domaine n’interfère pas avec les fonctionnalités liées à l’infrastructure, telles que la messagerie ou la persistance.
Déchargez les préoccupations transversales vers un service distinct. Réduisez la nécessité de dupliquer le code entre différentes fonctions, préférez réutiliser des services avec des interfaces bien définies qui peuvent être facilement consommées par différents composants. Par exemple, si plusieurs services doivent authentifier les demandes, vous pouvez déplacer cette fonctionnalité dans son propre service. Vous pouvez ensuite faire évoluer le service d’authentification. Par exemple, vous pouvez ajouter un nouveau flux d’authentification sans toucher les services qui l’utilisent.
Évaluez l’adéquation des modèles et pratiques courants pour vos besoins. Évitez de suivre les tendances ou recommandations qui peuvent ne pas être optimales pour votre contexte ou vos besoins. Par exemple, les microservices ne sont pas la meilleure option pour chaque application, car ils peuvent introduire des problèmes de complexité, de surcharge et de dépendance.
Développer suffisamment de code
Les principes de simplicité, d’efficacité et de fiabilité s’appliquent également à vos pratiques de développement. Dans une charge de travail faiblement couplée, composantée, déterminez les fonctionnalités qu’un composant fournit. Développez vos flux pour tirer parti de cette fonctionnalité. Tenez compte de ces recommandations pour vos pratiques de développement :
Utilisez des fonctionnalités de plateforme lorsqu’elles répondent aux besoins de votre entreprise. Par exemple, pour décharger le développement et la gestion, utilisez des solutions sans code, sans code ou serverless proposées par votre fournisseur de cloud.
Utilisez des bibliothèques et des frameworks.
Introduisez des sessions de programmation de paires ou de révision de code dédiées comme pratique de développement.
Implémentez une approche pour identifier le code mort. Soyez sceptique du code que vos tests automatisés ne couvrent pas.
Sélectionner le magasin de données approprié
Dans le passé, de nombreuses organisations stockaient toutes leurs données dans de grandes bases de données SQL relationnelles. Les bases de données relationnelles fournissent des garanties atomiques, cohérentes, isolées et durables (ACID) pour les transactions de données relationnelles. Mais ces bases de données présentent des inconvénients :
Les requêtes peuvent nécessiter des jointures coûteuses.
Vous devez normaliser les données et les restructurer pour le schéma en écriture.
La contention de verrouillage peut affecter les performances.
Alternatives aux bases de données relationnelles
Dans une grande solution, une seule technologie de magasin de données ne répond probablement pas à tous vos besoins. Les alternatives aux bases de données relationnelles sont les suivantes :
Magasins de paires clé-valeur
Bases de données de documents
Bases de données de moteur de recherche
Bases de données de séries chronologiques
Bases de données de familles de colonnes
Bases de données de graphe
Chaque option a des avantages et des inconvénients. Différents types de données conviennent mieux aux différents types de magasins de données. Choisissez la technologie de stockage la mieux adaptée à vos données et son mode d’utilisation.
Par exemple, vous pouvez stocker un catalogue de produits dans une base de données de documents, telle que Azure Cosmos DB, qui prend en charge un schéma flexible. Chaque description de produit est un document autonome. Pour lancer des requêtes sur la totalité du catalogue, vous devrez peut-être indexer le catalogue et stocker l’index dans Recherche cognitive Azure. L’inventaire des produits peut entrer dans une base de données SQL, car ces données nécessitent des garanties ACID.
Recommandations
Envisagez d’autres magasins de données. Les bases de données relationnelles ne sont pas toujours appropriées. Pour plus d’informations, consultez Comprendre les modèles de magasin de données.
N’oubliez pas que les données représentent bien plus que les données d’application persistantes. Elles incluent également les journaux des applications, les événements, les messages et les caches.
Adoptez la persistance polyglotte ou les solutions qui utilisent une combinaison de technologies de magasin de données.
Considérez le type de données dont vous disposez. Par exemple, stockez :
Données transactionnelles dans une base de données SQL.
Documents JSON dans une base de données de documents.
Télémétrie dans une base de données de série chronologique.
Journaux d’application dans Recherche cognitive Azure.
Objets blob dans Stockage Blob Azure.
Hiérarchiser la disponibilité par rapport à la cohérence. Le théorème CAP implique que vous devez faire des compromis entre disponibilité et cohérence dans un système distribué. Vous ne pouvez pas éviter complètement les partitions réseau, qui est l’autre composant du théorème CAP. Toutefois, vous pouvez adopter un modèle de cohérence éventuel pour obtenir une disponibilité plus élevée.
Prenez en compte les compétences de votre équipe de développement. Si la persistance polyglotte offre de nombreux avantages, elle peut également s’avérer très complexe. Il nécessite de nouveaux ensembles de compétences pour adopter une nouvelle technologie de stockage de données. Pour tirer le meilleur parti de la technologie, votre équipe de développement doit :
Optimiser les requêtes.
Optimiser les performances.
Utilisez les modèles d’utilisation appropriés.
Tenez compte de ces facteurs lorsque vous choisissez une technologie de stockage :
Utilisez des transactions de compensation. Avec la persistance polyglotte, une transaction unique peut écrire des données dans plusieurs magasins. En cas d’échec, utilisez des transactions de compensation pour annuler les étapes terminées.
Considérez les contextes délimités, qui est un concept de conception piloté par le domaine. Une limite de contexte est une limite explicite autour d’un modèle de domaine. Un contexte limité définit les parties du domaine auquel le modèle s’applique. Dans l’idéal, une limite de contexte correspond à un sous-domaine du domaine d’entreprise. Considérez la persistance polyglotte pour les contextes délimités dans votre système. Par exemple, les produits peuvent apparaître dans le sous-domaine du catalogue de produits et le sous-domaine inventaire des produits. Toutefois, ces deux sous-domaines ont probablement des exigences différentes pour le stockage, la mise à jour et l’interrogation de produits.
Facilitation Azure
Azure offre les services suivants :
Azure Functions est un service de calcul serverless que vous pouvez utiliser pour créer une orchestration avec un code minimal.
Azure Logic Apps est une plateforme d’intégration de flux de travail serverless que vous pouvez utiliser pour créer une orchestration avec une interface graphique graphique utilisateur ou en modifiant un fichier de configuration.
Azure Event Grid est un service de distribution de messages à abonnement à publication entièrement managé hautement évolutif qui offre des modèles de consommation de messages flexibles qui utilisent les protocoles MQTT et HTTP. Avec Event Grid, vous pouvez créer des pipelines de données avec des données d’appareil, créer des architectures serverless pilotées par les événements et intégrer des applications.
Pour plus d’informations, consultez l’article suivant :
- Choisir un service de calcul Azure
- Choisir une option de calcul pour les microservices
- Passer en revue vos options de données
Exemple
Pour obtenir un exemple de charge de travail qui détermine les composants et leurs fonctionnalités en fonction des exigences, consultez le modèle Reliable Web App.
Liens connexes
Liste de contrôle de fiabilité
Reportez-vous à l’ensemble complet de recommandations.