Sostenibilità come requisito non funzionale - Principio della sostenibilità

Sostenibilità come requisito non funzionale

Aggiungere la sostenibilità al proprio elenco di requisiti aziendali può consentire di ottenere risultati più vantaggiosi dal punto di vista dei costi. Se ti focalizzi su come ottenere maggior valore dalle risorse usandone di meno, ottieni direttamente una riduzione dei costi su AWS, poiché paghi solo ciò che usi.

Soddisfare gli obiettivi di sostenibilità non comporta necessariamente compromessi in altre metriche tradizionali, come i tempi di attività, la disponibilità o i tempi di risposta. Tuttavia, spesso è possibile ottenere vantaggi significativi in termini di sostenibilità senza alcun impatto misurabile sui livelli di servizio. Laddove sono richiesti piccoli compromessi, il miglioramento in termini di sostenibilità così ottenuto può superare il cambiamento in termini di qualità del servizio.

Incoraggia i membri del tuo team a sperimentare continuamente migliorie in termini di sostenibilità durante la fase di sviluppo di requisiti funzionali. I team devono anche integrare metriche relative ai proxy nella fase di definizione degli obiettivi per avere la certezza di valutare l'intensità delle risorse durante lo sviluppo dei carichi di lavoro.

Ecco alcuni esempi dei compromessi che possono ridurre le risorse cloud che usi:

Adegua la qualità del risultato: Puoi scambiare la Quality of Results (QoR) in favore di una riduzione dell'intensità del carico di lavoro con un calcolo approssimativo. La pratica dell'elaborazione approssimativa cerca opportunità per sfruttare il divario tra ciò che è assolutamente necessario e ciò che effettivamente produci. Ad esempio, se i dati vengono inseriti in una struttura di dati impostata , puoi eliminare l'operatore ORDER BY in SQL per rimuovere elaborazioni superflue, ridurre l'uso di risorse e offrire, al tempo stesso, una risposta accettabile.

Adegua i tempi di risposta: Una risposta con un tempo di risposta più lento può favorire il risparmio di anidride carbonica, riducendo al minimo il sovraccarico condiviso. L'elaborazione di attività temporanee ad hoc può comportare un sovraccarico in fase di avvio. Raggruppa le attività ed elaborale in batch, invece di pagare per il sovraccarico ogni volta che arriva un'attività. L'elaborazione in batch implica l'aumento del tempo di risposta in cambio di una riduzione del sovraccarico condiviso della creazione di un'istanza, del download del codice sorgente e dell'esecuzione del processo.

Adegua la disponibilità: AWS consente di aggiungere facilmente ridondanza e di raggiungere target di elevata disponibilità con pochi e semplici clic. Puoi aumentare la ridondanza con tecniche come la stabilità statica, eseguendo il provisioning di risorse inattive che comportano sempre una riduzione dell'utilizzo. Valuta le esigenze dell'azienda quando definisci gli obiettivi. Compromessi relativamente minori in termini di disponibilità possono portare a miglioramenti molto più significativi in termini di utilizzo. Ad esempio, un modello di architettura di stabilità statica prevede il provisioning della capacità di failover inattiva per assorbire immediatamente il carico dopo un guasto di un componente. Allentare i requisiti di disponibilità può eliminare la necessità di capacità online inattiva consentendo all'automazione di distribuire risorse sostitutive. L'aggiunta di capacità di failover on demand consente un utilizzo complessivo più elevato senza alcun impatto sull'attività durante le normali operazioni e offre il vantaggio secondario di ridurre i costi.