Green Software Patterns

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

Poiché siamo molto allineati con gli obiettivi della Green Software Foundation, abbiamo voluto portare all’attenzione di tutti alcuni di questi pattern applicati nel contesto di DownToZero.Cloud.

• Green Software Patterns

Artificial Intelligence (AI)

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

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

Cloud

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

Cache static data

Dal punto di vista dell’efficienza energetica, è meglio ridurre il traffico di rete leggendo i dati localmente tramite una cache anziché accedervi da remoto attraverso la rete.

Effettuiamo caching in molte istanze durante l’elaborazione delle richieste, ad esempio il nostro runtime per job asincroni memorizza localmente le immagini docker, evitando così un pull completo ad ogni invocazione.

Utilizziamo inoltre, per quanto possibile, gli hash delle immagini per le immagini container al fine di ridurre il carico in tempo reale durante l’istanziazione di nuovi container.

Choose the region that is closest to users

Dal punto di vista dell’efficienza energetica, è meglio accorciare la distanza che un pacchetto di rete deve percorrere in modo da richiedere meno energia per la trasmissione. Analogamente, dal punto di vista della carbon footprint incorporata, quando un pacchetto di rete attraversa meno apparecchiature di calcolo, siamo più efficienti nell’uso dell’hardware.

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

Compress stored data

Memorizzare troppi dati non compressi può causare spreco di banda e aumentare i requisiti di capacità di archiviazione.

Siamo impegnati a memorizzare solo dati compressi.

Sia Objectstore che Container Registry supportano la compressione a livello di storage. Questa è integrata 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.

Compress transmitted data

Dal punto di vista dell’efficienza energetica, è meglio ridurre al minimo la dimensione dei dati trasmessi così da richiedere meno energia per via del traffico di rete ridotto.

Containerize your workloads

I container permettono di usare le risorse in modo più flessibile, poiché i carichi di lavoro possono essere facilmente spostati tra macchine. I container consentono il bin packing e richiedono meno risorse di calcolo rispetto alle macchine virtuali, il che implica una riduzione nell’allocazione non necessaria di risorse e un aumento dell’utilizzo delle risorse di calcolo.

Supportiamo solo carichi di lavoro containerizzati. La possibilità di spostare carichi di lavoro tra location è fondamentale in DTZ per permettere lo spostamento dei workload verso ambienti di esecuzione più efficienti su richiesta.

Delete unused storage resources

Dal punto di vista della carbon footprint incorporata, è meglio eliminare le risorse di archiviazione inutilizzate in modo da usare l’hardware in modo efficiente e ottimizzare lo strato di storage per il compito.

Il nostro object store supporta scadenze sugli oggetti, quindi ogni entità può essere rimossa una volta che non è più usata. Anche il nostro container registry esegue job di pulizia configurabili per ridurre il numero degli oggetti memorizzati.

Encrypt what is necessary

La protezione dei dati mediante crittografia è un aspetto cruciale delle nostre misure di sicurezza. Tuttavia, il processo di crittografia può essere dispendioso in termini di risorse a vari livelli. In primo luogo, la quantità di CPU richiesta per la crittografia varia a seconda dell’algoritmo scelto, e algoritmi più complessi tendono a richiedere maggior potenza di calcolo. Inoltre, la crittografia può aumentare i requisiti di storage poiché gonfia la dimensione dei dati memorizzati in quanto contiene tipicamente metadati aggiuntivi e padding, particolarmente evidente per file di dimensioni ridotte. Inoltre, la crittografia è un’attività ripetitiva che deve essere eseguita ogni volta che i dati vengono recuperati o aggiornati. Questa natura ripetitiva può contribuire a un aumento del consumo energetico, specialmente in sistemi ad alto throughput.

Evaluate other CPU architectures

Le applicazioni vengono costruite con un’architettura software che meglio si adatta alle esigenze di business che servono. I fornitori cloud facilitano la valutazione di altri tipi di CPU, come x86-64, che possono essere inclusi nella valutazione insieme a molte alternative a basso costo che offrono una buona performance per watt.

Per ora supportiamo solo una singola architettura CPU, x86. Attualmente non abbiamo risorse per valutare altre architetture.

Use a service mesh only if needed

Un service mesh distribuisce container aggiuntivi per la comunicazione, tipicamente in un pattern sidecar, per fornire capacità operative maggiori. Questo può comportare un aumento nell’uso della CPU e nel traffico di rete ma permette anche di disaccoppiare la tua applicazione da queste capacità, spostandole dallo strato applicativo a quello infrastrutturale.

Poiché la nostra rete non si basa su astrazioni Kubernetes, non ne facciamo uso.

Terminate TLS at border gateway

Transport Layer Security (TLS) garantisce che tutti i dati scambiati tra il server web e i browser rimangano privati e crittografati. Tuttavia, terminare e ristabilire TLS aumenta l’uso della CPU e potrebbe essere non necessario in certe architetture.

Implement stateless design

Lo stato di servizio si riferisce ai dati in memoria o su disco necessari a un servizio per funzionare. Lo stato include le strutture dati e le variabili membro che il servizio legge e scrive. A seconda dell’architettura del servizio, lo stato potrebbe includere anche file o altre risorse memorizzate su disco.

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

Match your service level objectives to business needs

Se i downtime di servizio sono accettabili è meglio non puntare alla massima disponibilità ma progettare la soluzione in base alle reali esigenze di business. Garanzie di disponibilità più basse possono aiutare a ridurre il consumo energetico usando meno componenti infrastrutturali.

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

Match utilization requirements of virtual machines (VMs)

È meglio avere una VM che gira a elevata utilizzazione che due a bassa utilizzazione, non solo in termini di proporzionalità energetica ma anche in termini di carbon footprint incorporata.

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

È meglio avere una VM che gira a elevata utilizzazione che due a bassa utilizzazione, non solo in termini di proporzionalità energetica ma anche in termini di carbon footprint incorporata.

Puntiamo a un’alta utilizzazione nella nostra infrastruttura, ma questi componenti non sono direttamente 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 una data applicazione, potrebbe essere necessario utilizzare più ambienti nel workflow dell’applicazione. Tipicamente, un ambiente di sviluppo è usato per aggiornamenti regolari, mentre ambienti di staging o test sono utilizzati per assicurare che non vi siano problemi prima che il codice raggiunga l’ambiente di produzione accessibile dagli utenti.

Optimise storage utilization

È meglio massimizzare l’utilizzo dello storage in modo che lo strato di archiviazione sia ottimizzato per il compito, non solo in termini di proporzionalità energetica ma anche in termini di carbon footprint incorporata.

Optimize average CPU utilization

L’uso e l’utilizzo della CPU variano durante il giorno, a volte drasticamente per diversi requisiti computazionali. Più grande è la differenza tra il valore medio e il picco di utilizzo della CPU, maggiori risorse devono essere messe in standby per assorbire i picchi di traffico.

Optimize impact on customer devices and equipment

Le applicazioni girano su hardware del cliente o sono visualizzate su di esso. L’hardware usato dal cliente ha un’impronta di carbonio incorporata prodotta tramite la produzione e l’elettricità richiesta durante il funzionamento. Ottimizzare il design e l’architettura software per estendere la vita dei dispositivi del cliente riduce l’intensità di carbonio dell’applicazione. Idealmente il cliente può usare l’hardware fino al guasto o fino a quando diventa obsoleto.

Optimize peak CPU utilization

L’uso e l’utilizzo della CPU variano durante il giorno, a volte drasticamente per diversi requisiti computazionali. Più grande è la differenza tra il valore medio e il picco di utilizzo della CPU, maggiori risorse devono essere messe in standby per assorbire i picchi di traffico.

Queue non-urgent processing requests

Tutti i sistemi hanno periodi di carico elevato e basso. Dal punto di vista dell’efficienza hardware, siamo più efficienti se minimizziamo l’impatto dei picchi di richieste con un’implementazione che consenta un utilizzo uniforme dei componenti. Dal punto di vista dell’efficienza energetica, siamo più efficienti se assicuriamo che le risorse inattive siano mantenute al minimo.

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

Reduce transmitted data

Dal punto di vista dell’efficienza energetica, è meglio minimizzare la dimensione dei dati trasmessi così da richiedere meno energia per via del traffico di rete ridotto.

Remove unused assets

Monitora e analizza l’applicazione e la bolletta cloud per identificare risorse che non sono più utilizzate o che possono essere ridotte.

Scale down kubernetes applications when not in use

Per ridurre emissioni di carbonio e costi, i cluster Kubernetes per Dev&Test possono spegnere i nodi (VM) fuori orario d’ufficio (ad esempio di notte e nei weekend). => l’ottimizzazione viene quindi implementata a livello di cluster.

Non offriamo servizi basati su Kubernetes.

Scale down applications when not in use

Le applicazioni consumano CPU anche quando non sono attivamente in uso. Ad esempio timer in background, garbage collection, health check ecc. Anche quando l’applicazione è spenta, l’hardware sottostante consuma energia in idle. Ciò può avvenire anche per applicazioni di sviluppo e test o hardware fuori orario d’ufficio.

DownToZero, come suggerisce il nome, ha al centro delle sue attività lo scaling down. Pertanto puntiamo a che tutti i servizi supportino lo scale-down.

Scale infrastructure with user load

La domanda di risorse dipende dal carico utente in un dato momento. Tuttavia, la maggior parte delle applicazioni non tiene conto di questo. Di conseguenza, le risorse sono sottoutilizzate e inefficienti.

Scale Kubernetes workloads based on relevant demand metrics

Per impostazione predefinita, Kubernetes scala i workload in base all’utilizzo della CPU e della RAM. In pratica, però, è difficile correlare i driver di domanda della tua applicazione con l’utilizzo di CPU e RAM.

Non offriamo servizi Kubernetes.

Scale logical components independently

Un’architettura a microservizi può ridurre la quantità di risorse computazionali richieste in quanto permette di scalare ogni componente indipendente in base alla sua domanda.

Scan for vulnerabilities

Molti attacchi alle infrastrutture cloud mirano a un uso improprio delle risorse distribuite, il che porta a picchi ingiustificati nell’uso e nei costi.

Set storage retention policies

Dal punto di vista della carbon footprint incorporata, è meglio avere un meccanismo automatico per eliminare le risorse di archiviazione inutilizzate così da essere efficienti con l’hardware e ottimizzare lo strato di storage per il compito.

Shed lower priority traffic

Quando le risorse sono limitate durante eventi di traffico elevato o quando l’intensità di carbonio è alta, il tuo sistema produrrà più emissioni di carbonio. Aggiungere risorse per supportare un traffico maggiore introduce più carbon footprint incorporata e più richiesta di elettricità. Continuare a gestire tutte le richieste durante alta intensità di carbonio aumenterà le emissioni complessive del sistema. Ridurre il traffico di bassa priorità in questi scenari salverà risorse e emissioni di carbonio. Questo approccio richiede una conoscenza del proprio traffico, incluse quali richieste sono critiche e quali possono tollerare tentativi di retry e fallimenti.

Time-shift Kubernetes cron jobs

Le emissioni di carbonio di un sistema software dipendono dall’energia consumata da quel software, ma anche dall’intensità di carbonio dell’elettricità con cui è alimentato. Per questo motivo, eseguire software efficienti dal punto di vista energetico su una rete elettrica ad alta intensità di carbonio potrebbe essere inefficiente nel ridurre le emissioni globali di carbonio.

Sebbene non offrendo servizi Kubernetes, i nostri Container Jobs offrono la possibilità di un modello di scheduling flessibile. Consulta la nostra doc per maggiori informazioni.

Use Asynchronous network calls instead of synchronous

Quando si effettuano chiamate tra processi verso database, file system o REST API, affidarsi a chiamate sincrone può bloccare il thread chiamante, causando un carico aggiuntivo sulla CPU.

Use circuit breaker patterns

Le applicazioni moderne devono comunicare regolarmente con altre applicazioni. Poiché queste altre applicazioni hanno programmazioni di deployment, downtime e disponibilità propri, la connessione di rete verso queste applicazioni può avere problemi. Se l’altra applicazione non è raggiungibile, tutte le richieste di rete verso questo servizio falliranno e le chiamate future sono inutili.

Use cloud native network security tools and controls

Firewall di rete e per applicazioni web offrono protezione contro gli attacchi più comuni e mitigano i bad bots. Questi strumenti aiutano a rimuovere trasmissioni di dati non necessarie e riducono il carico sull’infrastruttura cloud, usando anche meno banda e meno infrastruttura.

Use DDoS protection

Gli attacchi Distributed Denial of Service (DDoS) vengono utilizzati per aumentare il carico su un server in modo che non possa rispondere a richieste legittime. Di solito si fanno per danneggiare il proprietario del servizio o dell’hardware. A causa della natura dell’attacco, molte risorse ambientali vengono consumate da richieste insensate.

Use cloud native processor VMs

Le macchine virtuali cloud hanno capacità diverse in base ai processori hardware su cui poggiano. Usare VM basate sull’efficienza dei loro processori influirà sull’efficienza hardware e ridurrà le emissioni di carbonio.

Use serverless cloud services

I servizi cloud serverless sono servizi gestiti dal provider cloud per l’applicazione. Scalano dinamicamente in base al carico di lavoro necessario per svolgere il compito di servizio e applicano best practices per mantenere l’uso delle risorse minimo.

Tutte le offerte di DownToZero sono servizi cloud serverless.

Web

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

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