Green Software Patterns
The Green Software Foundation maintains the Green Software Patterns: a curated collection of practices for building greener software.
The catalogue is organized by the software lifecycle and can also be explored by role:
The patterns below are the ones most relevant to the DownToZero platform. Each heading links to the pattern’s current location in the catalogue, followed by how we apply it—or where it does not yet apply—to DownToZero.
Patterns at DownToZero
Cache static data
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.
Stiamo usando la cache in molte istanze durante l’elaborazione delle richieste, ad es. il nostro runtime per job asincroni memorizza localmente nella cache le immagini Docker, quindi non è necessario un pull completo ad ogni invocazione.
Stiamo anche usando gli hash delle immagini per le immagini dei container tanto quanto possibile per ridurre il carico in tempo reale durante l’istanza di nuovi container.
Choose the region that is closest to users
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-region, o non esponiamo direttamente la disposizione 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à.
Compress stored data
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 “hot” a un formato più freddo e meglio compresso dopo un periodo di retention fisso.
Compress transmitted data
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.
Containerize your workloads
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 località è necessaria al centro di DTZ per consentire lo spostamento di carichi di lavoro verso ambienti di esecuzione più efficienti su richiesta.
Delete unused storage resources
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 scadenze sugli oggetti, in modo che ogni entità possa essere ripulita dopo che non è più utilizzata. Anche il nostro container registry esegue job di cleanup configurabili per ridurre la quantità di oggetti memorizzati.
Encrypt what is necessary
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.
Evaluate other CPU architectures
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.
Use a service mesh only if needed
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.
Dato che la nostra rete non si basa su astrazioni Kubernetes, non abbiamo nemmeno bisogno di un service mesh.
Terminate TLS at 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.
Implement stateless design
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 portano anche queste capacità ai nostri utenti.
Match your service level objectives to business needs
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à. Perciò i nostri servizi dipendono fortemente dallo scaling automatico per fornire sempre un livello di servizio appropriato con il minimo overhead.
Match utilization requirements of virtual machines (VMs)
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.
Match utilization requirements with pre-configured servers
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’elevata utilizzazione nella nostra infrastruttura, ma quei 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.
Minimize the total number of deployed environments
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.
Optimise storage utilisation
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.
Optimize average CPU utilization
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.
Optimize impact on customer devices and equipment
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.
Optimize peak CPU utilization
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.
Queue non-urgent processing requests
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 questo obiettivo come servizio all’interno di DTZ.
Reduce transmitted data
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.
Remove unused assets
Monitor and analyze the application and the cloud bill to identify resources that are no longer used or can be reduced.
Scale down kubernetes applications when not in use
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.
Scale down applications when not in use
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, lo scaling verso zero è al centro delle nostre attività. Perciò puntiamo a far sì che tutti i servizi forniscano meccanismi di scale-down.
Scale infrastructure with user load
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.
Scale Kubernetes workloads based on relevant demand metrics
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.
Scale logical components independently
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.
Scan for vulnerabilities
Many attacks on cloud infrastructure seek to misuse deployed resources, which leads to an unnecessary spike in usage and cost.
Set storage retention policies
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.
Shed lower priority traffic
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.
Time-shift Kubernetes cron jobs
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, i nostri Container Jobs offrono la possibilità di un modello di scheduling flessibile. Vedi la nostra docs per maggiori informazioni.
Use Asynchronous network calls instead of synchronous
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.
Use circuit breaker patterns
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.
Use cloud native network security tools and controls
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.
Use DDoS protection
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.
Use cloud native processor VMs
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.
Use serverless cloud services
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.
All offerings of DownToZero are serverless cloud services.