Durabilité en tant qu’exigence non fonctionnelle - Pilier de durabilité

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Durabilité en tant qu’exigence non fonctionnelle

L’ajout de la durabilité à votre liste d’exigences métiers peut générer des solutions plus rentables. Le fait de s'efforcer de tirer le meilleur parti des ressources que vous utilisez et d'en utiliser moins se traduit directement par des économies, AWS car vous ne payez que pour ce que vous utilisez.

La réalisation des objectifs de durabilité peut ne pas nécessiter de compromis équivalents dans une ou plusieurs autres métriques traditionnelles telles que le temps de fonctionnement, la disponibilité ou le temps de réponse. Vous pouvez réaliser des gains significatifs en matière de durabilité sans impact mesurable sur les résultats des services. Lorsque des compromis mineurs sont nécessaires, les améliorations de la durabilité obtenues grâce à ces compromis peuvent l’emporter sur la modification de la qualité du service.

Encouragez les membres de votre équipe à expérimenter continuellement des améliorations en matière de durabilité lors de l’élaboration des exigences fonctionnelles. Les équipes doivent également intégrer des métriques de substitution lors de la fixation des objectifs afin de s’assurer qu’elles évaluent l’intensité des ressources lors de l’élaboration de leurs charges de travail.

Voici des exemples de compromis permettant de réduire les ressources cloud que vous consommez :

Ajuster la qualité du résultat : vous pouvez effectuer un compromis sur la qualité des résultats (QoR) contre une réduction de l’intensité de la charge de travail grâce au calcul approximatif. La pratique du calcul approximatif recherche des opportunités d’exploitation de l’écart entre ce dont les clients ont besoin et ce que vous produisez réellement. Par exemple, si vous placez vos données dans une structure de données définie, vous pouvez ajouter l'opérateur ORDER BY SQL pour supprimer tout traitement inutile, économisant ainsi des ressources tout en fournissant une réponse acceptable.

Ajuster le temps de réponse : un temps de réponse plus lent peut permettre d’économiser du carbone en minimisant les frais généraux partagés. Le traitement des tâches éphémères ad hoc peut entraîner des frais généraux de démarrage. Groupez les tâches et traitez-les par lots au lieu de payer les frais généraux chaque fois qu’une tâche arrive. Le traitement par lots échange une augmentation du temps de réponse contre une réduction des frais généraux partagés liés au lancement d’une instance, au téléchargement du code source et à l’exécution du processus.

Ajuster la disponibilité : avec AWS, vous pouvez ajouter de la redondance et atteindre les objectifs de haute disponibilité en quelques clics. Vous pouvez augmenter la redondance grâce à des techniques comme la stabilité statique en provisionnant des ressources inactives qui entraînent toujours une diminution de l’utilisation. Évaluez les besoins de l’entreprise lors de la fixation des objectifs. Des compromis relativement mineurs en matière de disponibilité peuvent entraîner des améliorations beaucoup plus importantes en matière d’utilisation. Par exemple, le modèle d’architecture de stabilité statique consiste à mettre en service une capacité de basculement inutilisée pour une prise en charge immédiate après une défaillance d’un composant. Un relâchement des exigences de disponibilité peut supprimer le besoin de capacité en ligne inutilisée en laissant le temps à l’automatisation de déployer des ressources de remplacement. L’ajout de capacité de basculement à la demande entraîne une utilisation globale plus élevée, sans impact sur l’entreprise pendant les opérations normales, et présente l’avantage secondaire de réduire les coûts.