Green Software Patterns

La Green Software Foundation ha iniziato a lavorare su Green Software Patterns.

Dato che siamo molto allineati con gli obiettivi della Green Software Foundation, volevamo portare all’attenzione di tutti alcuni di questi pattern applicati nel contesto di DownToZero.Cloud.

• Green Software Patterns

Intelligenza Artificiale (AI)

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

Poiché non offriamo servizi correlati all’AI, saltiamo questa sezione del catalogo.

Cloud

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

Cache dei dati statici

From an energy-efficiency perspective, it’s better to reduce network traffic by reading the data locally through a cache rather than accessing it remotely over the network.

Effettuiamo caching in molte istanze durante l’elaborazione delle richieste, ad es. il nostro runtime per job asincroni mette in cache localmente le immagini docker, quindi non è necessario un pull completo ad ogni invocazione.

Utilizziamo inoltre hash delle immagini per i container il più possibile per ridurre il carico in tempo reale durante l’istanziamento di nuovi container.

Scegliere la regione più vicina agli utenti

From an energy-efficiency perspective, it’s better to shorten the distance a network packet travels so that less energy is required to transmit it. Similarly, from an embodied-carbon perspective, when a network packet traverses through less computing equipment, we are more efficient with hardware.

Poiché non siamo multi-regione, né esponiamo direttamente la topologia regionale della nostra infrastruttura, questo non può essere influenzato dall’utente. Internamente cerchiamo di ottimizzare la regionalità il più possibile, senza sacrificare durabilità e disponibilità.

Comprimere i dati memorizzati

Storing too much uncompressed data can result in bandwidth waste and increase the storage capacity requirements.

Siamo impegnati a memorizzare solo dati compressi.

Sia l’Objectstore che il Container Registry supportano la compressione a livello di storage. Questo è integrato in entrambi i servizi. Il servizio di Observability ha un meccanismo interno di tiering che sposta i dati da un livello di storage caldo a un formato più freddo e meglio compresso dopo un periodo di retention fisso.

Comprimere i dati trasmessi

From an energy-efficiency perspective, it’s better to minimise the size of the data transmitted so that less energy is required because the network traffic is reduced.

Containerizzare i workload

Containers allow resources to be used more flexibly, as workloads can be easily moved between machines. Containers allow for bin packing and require less compute resources than virtual machines, meaning a reduction in unnecessary resource allocation and an increase in utilization of the compute resources.

Supportiamo solo workload containerizzati. La possibilità di spostare i workload tra posizioni è necessaria al centro di DTZ per consentire lo spostamento dei carichi verso ambienti di esecuzione più efficienti su richiesta.

Eliminare risorse di storage non utilizzate

From an embodied carbon perspective, it’s better to delete unused storage resources so we are efficient with hardware and so that the storage layer is optimised for the task.

Il nostro object store supporta expiration sugli oggetti, così ogni entità può essere rimossa quando non è più utilizzata. Anche il nostro container registry esegue job di pulizia configurabili per ridurre la quantità di oggetti memorizzati.

Cifrare solo ciò che è necessario

Data protection through encryption is a crucial aspect of our security measures. However, the encryption process can be resource-intensive at multiple levels. Firstly, the amount of CPU required for encryption varies depending on the chosen algorithm, and more complex algorithms tend to demand higher computational power. Additionally, encryption can lead to increased storage requirements as it inflates the size of the data being stored because it typically contains additional metadata and padding, which is especially noticeable for smaller files. Furthermore, encryption is a repetitive task that needs to be performed each time data is fetched or updated. This repetitive nature can contribute to increased energy consumption, especially in high-throughput systems.

Valutare altre architetture CPU

Applications are built with a software architecture that best fits the business need they are serving. Cloud providers make it easy to evaluate other CPU types, such as x86-64, which can be included in the evaluation along with many cost effective alternatives that feature good performance per watt.

Per ora supportiamo solo una singola architettura CPU, X86. Attualmente non abbiamo le risorse per valutare architetture differenti.

Usare un service mesh solo se necessario

A service mesh deploys additional containers for communication, typically in a sidecar pattern, to provide more operational capabilities. This can result in an increase in CPU usage and network traffic but also allows you to decouple your application from these capabilities, moving them out from the application layer and down to the infrastructure layer.

Poiché la nostra rete non si basa su astrazioni di kubernetes, non abbiamo bisogno di un service mesh.

Terminare TLS al border gateway

Transport Layer Security (TLS) ensures that all data passed between the web server and web browsers remain private and encrypted. However, terminating and re-establishing TLS increases CPU usage and might be unnecessary in certain architectures.

Implementare un design stateless

Service state refers to the in-memory or on-disk data required by a service to function. State includes the data structures and member variables that the service reads and writes. Depending on how the service is architected, the state might also include files or other resources stored on the disk.

I nostri servizi esistenti, come Container Services e Container Jobs, si basano su un design stateless e offrono anche queste capacità ai nostri utenti.

Allineare gli obiettivi di livello di servizio alle esigenze di business

If service downtimes are acceptable it’s better to not strive for highest availability but to design the solution according to real business needs. Lower availability guarantees can help reduce energy consumption by using less infrastructure components.

Il nostro SLO è fornire il miglior servizio possibile, senza compromettere efficienza e sostenibilità. Pertanto i nostri servizi dipendono fortemente dallo scaling automatico per garantire sempre un livello di servizio appropriato con il minimo overhead.

Allineare i requisiti di utilizzo delle macchine virtuali (VM)

It’s better to have one VM running at a higher utilization than two running at low utilization rates, not only in terms of energy proportionality but also in terms of embodied carbon.

Finora non offriamo servizi basati su VM. Tutte le nostre offerte infrastrutturali si basano su container per offrire un’esperienza più snella.

Allineare i requisiti di utilizzo con server preconfigurati

It’s better to have one VM running at a higher utilization than two running at low utilization rates, not only in terms of energy proportionality but also in terms of embodied carbon.

Puntiamo a un’alta utilizzazione nella nostra infrastruttura, ma questi componenti non sono esposti all’utente finale. L’utente vede solo i container come astrazione. Poiché forniamo metriche di efficienza energetica, queste possono variare in base all’utilizzo dell’infrastruttura sottostante.

Minimizzare il numero totale di ambienti deployati

In a given application, there may be a need to utilize multiple environments in the application workflow. Typically, a development environment is used for regular updates, while staging or testing environments are used to make sure there are no issues before code reaches a production environment where users may have access.

Ottimizzare l’utilizzo dello storage

It’s better to maximise storage utilisation so the storage layer is optimised for the task, not only in terms of energy proportionality but also in terms of embodied carbon.

Ottimizzare l’utilizzo medio della CPU

CPU usage and utilization varies throughout the day, sometimes wildly for different computational requirements. The larger the variance between the average and peak CPU utilization values, the more resources need to be provisioned in stand-by mode to absorb those spikes in traffic.

Ottimizzare l’impatto sui dispositivi e sulle attrezzature dei clienti

Applications run on customer hardware or are displayed on it. The hardware used by the customer has a carbon footprint embodied through the production and electricity required while running. Optimising your software design and architecture to extend the life of the customer devices reduces the carbon intensity of the application. Ideally the customer can use the hardware until it’s failure or until it becomes obsolete.

Le applicazioni girano sull’hardware del cliente o vi vengono visualizzate. L’hardware usato dal cliente ha un’impronta carbonica incorporata nella produzione e nell’elettricità richiesta durante l’esecuzione. Ottimizzare il design e l’architettura del software per estendere la vita dei dispositivi dei clienti riduce l’intensità di carbonio dell’applicazione. Idealmente il cliente può usare l’hardware fino al guasto o fino a quando non diventa obsoleto.

Ottimizzare l’utilizzo massimo della CPU

CPU usage and utilization varies throughout the day, sometimes wildly for different computational requirements. The larger the variance between the average and peak CPU utilization values, the more resources need to be provisioned in stand-by mode to absorb those spikes in traffic.

Accodare le richieste di elaborazione non urgenti

All systems have periods of peak and low load. From a hardware-efficiency perspective, we are more efficient with hardware if we minimise the impact of request spikes with an implementation that allows an even utilization of components. From an energy-efficiency perspective, we are more efficient with energy if we ensure that idle resources are kept to a minimum.

Il nostro servizio Container Jobs è la manifestazione di quell’obiettivo come servizio all’interno di DTZ.

Ridurre i dati trasmessi

From an energy-efficiency perspective, it’s better to minimize the size of the data transmitted so that less energy is required because the network traffic is reduced.

Rimuovere asset inutilizzati

Monitor and analyze the application and the cloud bill to identify resources that are no longer used or can be reduced.

Ridurre le applicazioni kubernetes quando non in uso

In order to reduce carbon emissions and costs, Dev&Test Kubernetes clusters can turn off nodes (VMs) out of office hours (e.g at night & during weekends). => thereby, optimization is implemented at the cluster level.

Non offriamo servizi basati su Kubernetes.

Ridurre le applicazioni quando non in uso

Applications consume CPU even when they are not actively in use. For example, background timers, garbage collection, health checks, etc. Even when the application is shut down, the underlying hardware is consuming idle power. This can also happen with development and test applications or hardware in out-of-office hours.

DownToZero, come suggerisce il nome, ha lo scaling verso il basso al centro delle sue operazioni. Pertanto puntiamo a far sì che tutti i servizi forniscano meccanismi di scale-down.

Scalare l’infrastruttura con il carico degli utenti

Demand for resources depends on user load at any given time. However, most applications run without taking this into consideration. As a result,resources are underused and inefficient.

Scalare i workload Kubernetes in base a metriche di domanda rilevanti

By default, Kubernetes scales workloads based on CPU and RAM utilization. In practice, however, it’s difficult to correlate your application’s demand drivers with CPU and RAM utilization.

Non offriamo servizi Kubernetes.

Scalare componenti logici in modo indipendente

A microservice architecture may reduce the amount of compute resources required as it allows each independent component to be scaled according to its own demand.

Scansionare alla ricerca di vulnerabilità

Many attacks on cloud infrastructure seek to misuse deployed resources, which leads to an unnecessary spike in usage and cost.

Impostare politiche di retention per lo storage

From an embodied carbon perspective, it’s better to have an automated mechanism to delete unused storage resources so we are efficient with hardware and so that the storage layer is optimised for the task.

Rifiutare il traffico a bassa priorità

When resources are constrained during high-traffic events or when carbon intensity is high, more carbon emissions will be generated from your system. Adding more resources to support increased traffic requirements introduces more embodied carbon and more demand for electricity. Continuing to handle all requests during high carbon intensity will increase overall emissions for your system. Shedding traffic that is lower priority during these scenarios will save on resources and a carbon emissions. This approach requires an understanding of your traffic, including which call requests are critical and which can best withstand retry attempts and failures.

Spostare temporalmente i cron job di Kubernetes

The carbon emissions of a software system depends on the power consumed by that software, but also on the Carbon intensity of the electricity it is powered on. For this reason, running energy-efficient software on carbon intensive electricity grid, might be inefficient to reduce its global carbon emissions.

Pur non offrendo servizi Kubernetes, il nostro Container Jobs offre la possibilità di un modello di pianificazione flessibile. Vedi la nostra docs per maggiori informazioni.

Usare chiamate di rete asincrone invece di sincrone

When making calls across process boundaries to either databases or file systems or REST APIs, relying on synchronous calls can cause the calling thread to become blocked, putting additional load on the CPU.

Usare pattern circuit breaker

Modern applications need to communicate with other applications on a regular basis. Since these other applications have their own deployment schedule, downtimes and availability, the network connection to these application might have problems. If the other application is not reachable, all network requests against this other application will fail and future network requests are futile.

Usare strumenti e controlli di sicurezza di rete cloud native

Network & web application firewalls provide protection against most common attacks and load shedding bad bots. These tools help to remove unnecessary data transmission and reduce the burden on the cloud infrastructure, while also using lower bandwidth and less infrastructure.

Usare protezione DDoS

Distributed denial of service (DDoS) attacks are used to increase the server load so that it is unable to respond to any legitimate requests. This is usually done to harm the owner of the service or hardware. Due to the nature of attack, a lot of environmental resources are used up by nonsensical requests.

Usare VM con processori cloud native

Cloud virtual machines come with different capabilities based on different hardware processors. As such, using virtual machines based on the efficiency of their processors would impact hardware efficiency and reduce carbon emissions.

Usare servizi cloud serverless

Serverless cloud services are services that the cloud provider manages for the application. These scale dynamically with the workload needed to fulfill the service task and apply best practices to keep resource usage minimal.

Tutte le offerte di DownToZero sono servizi cloud serverless.

Web

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

Poiché non offriamo servizi correlati al Web, saltiamo questa sezione del catalogo.