Green Software Patterns

La Green Software Foundation a commencé à travailler sur les Green Software Patterns.

Étant donné que nous sommes très alignés avec les objectifs de la Green Software Foundation, nous souhaitons attirer l’attention de tous sur certains de ces patterns appliqués dans le contexte de DownToZero.Cloud.

• Green Software Patterns

Artificial Intelligence (AI)

https://patterns.greensoftware.foundation/catalog/ai/

Comme nous n’offrons aucun service lié à l’IA, nous passons cette section du catalogue.

Cloud

https://patterns.greensoftware.foundation/catalog/cloud/

Cache static data

D’un point de vue efficacité énergétique, il est préférable de réduire le trafic réseau en lisant les données localement via un cache plutôt que d’y accéder à distance via le réseau.

Nous utilisons le cache à de nombreuses reprises lors du traitement des requêtes, par exemple notre runtime de jobs asynchrones met en cache localement les images Docker, évitant ainsi un pull complet à chaque invocation.

Nous utilisons également des hashes d’images pour les images conteneur autant que possible afin de réduire la charge en temps réel lors de l’instanciation de nouveaux conteneurs.

Choose the region that is closest to users

D’un point de vue efficacité énergétique, il est préférable de raccourcir la distance parcourue par un paquet réseau afin de diminuer l’énergie nécessaire à sa transmission. De même, du point de vue du carbone incorporé, lorsqu’un paquet réseau traverse moins d’équipements informatiques, nous sommes plus efficaces avec le matériel.

Puisque nous ne sommes ni multi-région, ni ne dévoilons directement la répartition régionale de notre infrastructure, cela ne peut être influencé par un utilisateur.
En interne, nous tentons d’optimiser la régionalité autant que possible, sans compromettre la durabilité et la disponibilité.

Compress stored data

Stocker trop de données non compressées peut entraîner un gaspillage de bande passante et augmenter les besoins en capacité de stockage.

Nous nous engageons à ne stocker que des données compressées.

L’Objectstore et le Container Registry supportent la compression au niveau du stockage, cette fonctionnalité est intégrée dans les deux services.
Le service d’Observabilité dispose d’un mécanisme interne de tiering qui déplace les données d’un niveau de stockage chaud vers un format plus froid et mieux compressé après une période de rétention fixée.

Compress transmitted data

D’un point de vue efficacité énergétique, il est préférable de minimiser la taille des données transmises afin de réduire l’énergie requise car le trafic réseau est diminué.

Containerize your workloads

Les conteneurs permettent une utilisation plus flexible des ressources, car les workloads peuvent être facilement déplacés entre machines. Les conteneurs favorisent le bin packing et nécessitent moins de ressources informatiques que les machines virtuelles, ce qui réduit l’allocation de ressources non nécessaires et augmente l’utilisation des ressources de calcul.

Nous ne supportons que les workloads conteneurisés. Pouvoir déplacer les workloads entre différentes localisations est au cœur de DTZ pour permettre le déplacement vers des environnements d’exécution plus efficaces à la demande.

Delete unused storage resources

Du point de vue du carbone incorporé, il est préférable de supprimer les ressources de stockage inutilisées afin d’être efficace sur le matériel et d’optimiser la couche de stockage pour la tâche.

Notre magasin d’objets supporte les expirations des objets, permettant de nettoyer chaque entité une fois qu’elle n’est plus utilisée. Notre container registry exécute également des tâches de nettoyage configurables pour réduire le nombre d’objets stockés.

Encrypt what is necessary

La protection des données par chiffrement est un aspect crucial de nos mesures de sécurité. Cependant, le chiffrement peut être très gourmand en ressources à plusieurs niveaux. Tout d’abord, la quantité de CPU nécessaire dépend de l’algorithme choisi, les algorithmes plus complexes exigeant généralement plus de puissance de calcul. Ensuite, le chiffrement augmente souvent les besoins en stockage car il gonfle la taille des données stockées du fait des métadonnées et du rembourrage, ce qui est particulièrement visible pour les fichiers de petite taille. De plus, le chiffrement est une tâche répétitive à effectuer à chaque accès ou mise à jour des données, ce qui peut contribuer à une augmentation de la consommation énergétique, notamment dans des systèmes à haut débit.

Evaluate other CPU architectures

Les applications sont conçues avec une architecture logicielle correspondant au mieux au besoin métier qu’elles adressent. Les fournisseurs cloud facilitent l’évaluation d’autres types de CPU, comme x86-64, qui peuvent être intégrés dans l’évaluation avec de nombreuses alternatives économiques offrant un bon rapport performance par watt.

Pour l’instant, nous ne supportons qu’une seule architecture CPU, X86. Nous ne disposons pas actuellement des ressources pour évaluer différentes architectures.

Use a service mesh only if needed

Un service mesh déploie des conteneurs supplémentaires pour la communication, typiquement en mode sidecar, afin d’ajouter des capacités opérationnelles. Cela peut augmenter l’utilisation CPU et le trafic réseau mais permet de découpler ces fonctionnalités de l’application et de les déplacer de la couche application à la couche infrastructure.

Comme notre réseau ne repose sur aucune abstraction Kubernetes, nous n’avons pas non plus besoin d’un service mesh.

Terminate TLS at border gateway

Le Transport Layer Security (TLS) garantit que toutes les données échangées entre serveur web et navigateur restent privées et chiffrées. Cependant, terminer et rétablir TLS augmente l’utilisation CPU et peut être inutile dans certaines architectures.

Implement stateless design

L’état du service fait référence aux données en mémoire ou sur disque nécessaires au fonctionnement d’un service. L’état inclut les structures de données et variables membres que le service lit et écrit. Selon l’architecture du service, l’état peut aussi inclure des fichiers ou autres ressources stockées sur le disque.

Nos services existants, comme Container Services et Container Jobs, sont conçus selon un design sans état et offrent également ces capacités à nos utilisateurs.

Match your service level objectives to business needs

Si des temps d’arrêt sont acceptables, il vaut mieux ne pas viser la disponibilité maximale mais concevoir la solution selon les besoins réels du métier. Des garanties de disponibilité plus faibles peuvent aider à réduire la consommation d’énergie en utilisant moins de composants d’infrastructure.

Nos SLO visent à fournir le meilleur service possible sans compromettre l’efficacité et la durabilité. Nos services reposent donc fortement sur la mise à l’échelle automatique pour toujours fournir un niveau de service adapté avec un overhead minimal.

Match utilization requirements of virtual machines (VMs)

Il est préférable d’avoir une VM fonctionnant à forte utilisation plutôt que deux à faible taux d’utilisation, tant en termes de proportionnalité énergétique que de carbone incorporé.

Jusqu’à présent, nous n’offrons aucun service basé sur des machines virtuelles. Toutes nos offres d’infrastructure reposent sur des conteneurs pour offrir une expérience plus fluide.

Match utilization requirements with pre-configured servers

Il est préférable d’avoir une VM fonctionnant à forte utilisation plutôt que deux à faible taux d’utilisation, tant en termes de proportionnalité énergétique que de carbone incorporé.

Nous visons une forte utilisation de notre infrastructure, mais ces composants ne sont pas exposés à l’utilisateur final, qui ne voit que les conteneurs comme abstraction. Nous fournissons des métriques d’efficacité énergétique qui peuvent varier selon l’utilisation de l’infrastructure sous-jacente.

Minimize the total number of deployed environments

Dans une application donnée, plusieurs environnements peuvent être utilisés dans le workflow applicatif. Typiquement, un environnement de développement est utilisé pour les mises à jour régulières, tandis que des environnements de staging ou test servent à s’assurer qu’aucun problème n’apparaît avant que le code ne soit déployé en production accessible aux utilisateurs.

Optimise storage utilization

Il est préférable de maximiser l’utilisation du stockage afin que la couche de stockage soit optimisée pour la tâche, non seulement en termes de proportionnalité énergétique mais aussi de carbone incorporé.

Optimize average CPU utilization

L’utilisation du CPU varie tout au long de la journée, parfois de manière importante selon les besoins de calcul. Plus la différence entre l’utilisation moyenne et maximale du CPU est importante, plus de ressources doivent être prévues en mode veille pour absorber ces pics de trafic.

Optimize impact on customer devices and equipment

Les applications tournent sur le matériel client ou y sont affichées. Le matériel utilisé par le client a une empreinte carbone incorporée via la production et l’électricité consommée en fonctionnement. Optimiser la conception et l’architecture logicielle pour prolonger la durée de vie des équipements clients réduit l’intensité carbone de l’application. Idéalement, le client utilise son matériel jusqu’à sa panne ou son obsolescence.

Optimize peak CPU utilization

L’utilisation du CPU varie tout au long de la journée, parfois de manière importante selon les besoins de calcul. Plus la différence entre l’utilisation moyenne et maximale du CPU est importante, plus de ressources doivent être prévues en mode veille pour absorber ces pics de trafic.

Queue non-urgent processing requests

Tous les systèmes connaissent des périodes de charge maximale et faible. D’un point de vue efficacité matérielle, nous sommes plus efficaces si nous minimisons l’impact des pics de requêtes grâce à une implémentation permettant une utilisation régulière des composants. D’un point de vue efficacité énergétique, nous sommes plus efficaces si les ressources inactives sont minimisées.

Notre service Container Jobs incarne cet objectif en tant que service dans DTZ.

Reduce transmitted data

D’un point de vue efficacité énergétique, il est préférable de minimiser la taille des données transmises afin de réduire l’énergie requise car le trafic réseau est diminué.

Remove unused assets

Surveillez et analysez l’application ainsi que la facture cloud pour identifier les ressources inutilisées ou susceptibles d’être réduites.

Scale down kubernetes applications when not in use

Pour réduire les émissions de carbone et les coûts, les clusters Kubernetes Dev&Test peuvent éteindre des nœuds (VMs) en dehors des heures de bureau (par exemple la nuit et les week-ends). Ceci implémente une optimisation au niveau du cluster.

Nous ne proposons aucun service basé sur Kubernetes.

Scale down applications when not in use

Les applications consomment du CPU même lorsqu’elles ne sont pas activement utilisées, par exemple via des timers en arrière-plan, la collecte des déchets, des vérifications de santé, etc. Même arrêtée, l’infrastructure sous-jacente consomme de l’énergie au repos. Cela concerne aussi les applications de développement et test ou le matériel hors heures ouvrées.

DownToZero, comme son nom l’indique, place la mise à l’échelle descendante au cœur de ses activités. Nous visons donc à ce que tous les services proposent des réductions d’échelle automatiques.

Scale infrastructure with user load

La demande en ressources dépend de la charge utilisateur à un instant donné. Cependant, la plupart des applications ne tiennent pas compte de cela. En conséquence, les ressources sont sous-utilisées et inefficaces.

Scale Kubernetes workloads based on relevant demand metrics

Par défaut, Kubernetes adapte la charge en fonction de l’utilisation CPU et RAM. En pratique, il est difficile de corréler les facteurs de demande de votre application à l’utilisation du CPU et RAM.

Nous n’offrons aucun service Kubernetes.

Scale logical components independently

Une architecture microservices peut réduire la quantité de ressources de calcul nécessaires en permettant à chaque composant indépendant d’être mis à l’échelle selon sa propre demande.

Scan for vulnerabilities

De nombreuses attaques sur les infrastructures cloud cherchent à détourner des ressources déployées, ce qui entraîne une augmentation inutile de l’utilisation et des coûts.

Set storage retention policies

Du point de vue du carbone incorporé, il est préférable de disposer d’un mécanisme automatisé pour supprimer les ressources de stockage inutilisées afin d’être efficace avec le matériel et d’optimiser la couche de stockage pour la tâche.

Shed lower priority traffic

Lorsque les ressources sont limitées lors d’événements à fort trafic ou à forte intensité carbone, plus d’émissions de carbone seront générées par votre système. Ajouter des ressources pour gérer ces pics augmente le carbone incorporé et la demande en électricité. Continuer à traiter toutes les requêtes pendant ces pics augmente les émissions globales. Réduire le trafic de moindre priorité dans ces scénarios économise ressources et émissions. Cette approche nécessite une bonne compréhension de votre trafic, en distinguant les appels critiques de ceux supportant mieux tentatives de reprise et échecs.

Time-shift Kubernetes cron jobs

Les émissions carbone d’un système logiciel dépendent de la consommation d’énergie du logiciel mais aussi de l’intensité carbone de l’électricité utilisée. Pour cette raison, exécuter un logiciel économe en énergie sur un réseau électrique à forte intensité carbone peut être inefficace pour réduire ses émissions globales.

Bien que nous n’offrions pas de services Kubernetes, notre service Container Jobs propose un modèle de planification flexible. Voir notre docs pour plus d’informations.

Use Asynchronous network calls instead of synchronous

Lors d’appels entre processus vers bases de données, systèmes de fichiers ou API REST, utiliser des appels synchrones peut bloquer le thread appelant, augmentant la charge CPU.

Use circuit breaker patterns

Les applications modernes communiquent régulièrement entre elles. Comme ces autres applications ont leur propre planning de déploiement, leurs temps d’arrêt et disponibilité, la connexion réseau peut poser problème. Si l’autre application est injoignable, toutes les requêtes réseau échoueront et les requêtes futures seront inutiles.

Use cloud native network security tools and controls

Les firewalls réseau et web protègent contre les attaques courantes et réduisent la charge causée par les bots malveillants. Ces outils réduisent la transmission de données inutiles et la charge sur l’infrastructure cloud, tout en utilisant moins de bande passante et d’infrastructure.

Use DDoS protection

Les attaques par déni de service distribué (DDoS) visent à augmenter la charge du serveur pour qu’il ne puisse répondre aux requêtes légitimes. Ces attaques sont souvent faites pour nuire au propriétaire du service ou matériel. En raison de leur nature, ce sont des requêtes inutiles consommant beaucoup de ressources environnementales.

Use cloud native processor VMs

Les machines virtuelles cloud reposent sur différents processeurs matériels. Utiliser des VMs basées sur l’efficacité de leurs processeurs améliore l’efficacité matérielle et réduit les émissions carbone.

Use serverless cloud services

Les services cloud serverless sont gérés par le fournisseur cloud pour l’application. Ils s’adaptent dynamiquement à la charge de travail nécessaire et appliquent les meilleures pratiques pour minimiser l’utilisation des ressources.

Toutes les offres de DownToZero sont des services cloud serverless.

Web

https://patterns.greensoftware.foundation/catalog/web/

Puisque nous n’offrons aucun service lié au Web, nous passons cette section du catalogue.