Il nostro Blog

Ingegneria del software sostenibile (SSE) e il ruolo e le responsabilità di un ingegnere del software sostenibile

Ingegneria del software sostenibile (SSE) e il ruolo e le responsabilità di un ingegnere del software sostenibile

L'ingegneria del software sostenibile (SSE) tratta gli stessi argomenti dell'ottimizzazione del software o dell'ottimizzazione dei costi?

Cosa significa scrivere "software verde"? Internet ha molta letteratura su questo argomento, ma alla fine della storia c'è ancora molta confusione sul ruolo di un Sustainable Software Engineer e sulle sue responsabilità. Proviamo a chiarire meglio.

Se guardi ai principi dell'ingegneria del software verde, potresti trovare una serie di punti per ridurre le emissioni di carbonio prodotte dai server che eseguono le tue app, attraverso diversi tipi di ottimizzazioni. Questi punti possono indurti a pensare che stai seguendo le migliori pratiche SSE, ma guardando più da vicino, corrispondono esattamente alla guida classica nel software e nell'ottimizzazione dei costi. L'ottimizzazione delle app è un argomento ormai consolidato da diversi decenni, soprattutto con la crescita del cloud computing, quindi dove sono le novità?

Leggendo più attentamente, potresti trovare frasi come:

“In qualità di Green Software Engineer, riconosciamo che ci sono molti vantaggi nella creazione di applicazioni sostenibili. Sono quasi sempre più economici, spesso sono più performanti, spesso sono più resistenti. Ma il motivo principale per cui stiamo praticando l'ingegneria del software verde è per la sostenibilità, tutto il resto è un ulteriore vantaggio"

La mia interpretazione sull'argomento può essere riassunta in quel singolo concetto: quando ottimizzi le tue applicazioni, stai implementando contestualmente il tuo software verso modelli sostenibili. L'ottimizzazione del software e l'ottimizzazione dei costi sono chiaramente pratiche che riducono le emissioni di carbonio, ma questo risparmio è sostanzialmente un effetto collaterale (anche se molto gradito) derivato dalle ottimizzazioni stesse.

Come architetto del software, ho sempre scritto applicazioni secondo queste pratiche. Quindi, potrei affermare che sotto questi presupposti:

• Sono un bravo architetto
• Non sono un masochista informatico??

Gli architetti del software dovrebbero sempre sforzarsi di scrivere le applicazioni con le migliori prestazioni in termini di CPU, risorse e utilizzo della rete e in base al livello di servizio concordato con le parti interessate. La mia deduzione è quindi che le pratiche di ottimizzazione dei costi e del software sono minimamente correlate alla questione SSE.

I costi e l'ottimizzazione del software sono compiti per gli architetti. Le azioni intraprese per la creazione di software verde sono qualcosa di relativamente diverso, che deve giustificare il "valore aggiunto" dell'ESS. Quindi puoi indossare entrambi i cappelli, ma questa è un'altra storia.

SSE si occupa delle ottimizzazioni delle emissioni di carbonio in un data center specifico (cloud o on-premise)?

Le emissioni di carbonio di un'applicazione dipendono principalmente da due fattori principali:

1. Come l'applicazione è progettata e implementata
2. In quale ambiente viene distribuita l'applicazione e che tipo di risorse, fornite dall'ambiente, utilizza l'applicazione.

Solo il primo punto è responsabilità di un Sustainable Software Engineer. Il secondo è legato al datacenter e quanto gli ingegneri IT che operano in quel datacenter si preoccupano della causa della sostenibilità. Un SSE dovrebbe essere responsabile ma non responsabile per questo.

Supponiamo che la nostra applicazione sia costruita per essere verde (approfondiremo questi aspetti in seguito). Se distribuiamo questa app in un data center che non è conforme a pratiche sostenibili, l'intero sistema non è verde. Poiché non c'è nulla da fare a livello di applicazione, possiamo concludere che le ottimizzazioni del data center non sono strettamente correlate al ruolo SSE.

Per applicare questo concetto, diamo un'occhiata a tre possibili livelli di ottimizzazione in cui gli ingegneri IT possono operare per ottimizzare un ambiente e di conseguenza l'intero datacenter:

1. PUE (Power Usage Effectiveness): PUE è un rapporto tra l'intera potenza utilizzata dal data center e la potenza richiesta solo dai componenti hardware. È facile capire che questa metrica dipende solo dal data center stesso.
2. Fattore di emissione di carbonio (CEF): il CEF è la somma delle emissioni di CO2eq dell'attività umana descritta come unità di massa di CO2eq / flussi di riferimento. Anche questa metrica dipende solo dal datacenter stesso. Tieni presente che anche se stai passando al cloud e il tuo provider garantisce che i propri data center siano alimentati solo con energia alternativa, quel data center ha comunque emissioni di carbonio a causa delle emissioni di ambito 3. Ciò significa che l'implementazione di qualsiasi app su un data center completamente alimentato da alternative non è sufficiente per dichiararla 100% carbon free??
3. Hardware Optimization Factor (HOF): questo aspetto è il più difficile da gestire, e altrettanto difficile è affermare e dichiarare un hardware “ottimizzato” per le applicazioni che ospita. Sarebbe necessario un intero articolo per entrare nel dettaglio in una questione del genere quindi cercherò di riassumere un paio di concetti dedotti dal calcolo del carico computazionale nella maggior parte dei computer di nuova generazione:

• portare il carico computazionale (ovvero l'utilizzo della CPU sui server fisici) dal 10% al 40% aumenta solo di 1,7 volte l'assorbimento di potenza necessario per quel server.
• Se il carico computazionale è vicino allo 0% (le app sono inattive o assenti), il server fisico ha ancora un notevole assorbimento di energia, il che è controproducente in termini di efficienza delle emissioni di carbonio.

La virtualizzazione, la containerizzazione e – soprattutto – l'utilizzo delle risorse cloud PaaS sono i principali fattori che consentono a un datacenter di mantenere ottimizzata la metrica del carico computazionale. Come PUE e CEF, anche questa pratica di ottimizzazione dipende solo dall'organizzazione del data center e di conseguenza non è un'attività SSE.

Quindi, di cosa dovrebbe essere responsabile un ingegnere del software sostenibile?

Uno dei principali errori che un ingegnere del software sostenibile potrebbe commettere è iniziare a misurare le metriche di utilizzo di tutte le risorse utilizzate dal software e arrivare troppo rapidamente a conclusioni fallaci. SSE non riguarda (solo) i KPI del consumo di risorse. Possono essere utili, ma solo se contestualizzati con altri valori più rilevanti.

Facciamo un esempio: potresti misurare un enorme utilizzo delle risorse per la tua app, in termini di CPU, memoria e networking. Dopo averli misurati, potresti di conseguenza pensare: “oh mio Dio, la mia applicazione non è affatto verde!”. Niente di più sbagliato: se esegui un'applicazione critica della NASA che governa tutti i satelliti USA nello spazio, probabilmente quell'app sarebbe una sanguisuga di risorse. Al contrario, se puoi dimostrare che è ottimizzato per le risorse hardware, allora potrebbe essere perfettamente verde.

Facciamo un altro esempio: scrivo un'applicazione che gestisce campionati di fantacalcio. Quell'applicazione è incredibilmente veloce! Carica le pagine in termini di millisecondi, legge i dati localmente rapidamente, memorizza nella cache la maggior parte dei dati in modo intelligente e conserva i dati in modo intelligente.

• La risorsa dell'applicazione è ottimizzata? Partendo dal presupposto che io sia un buon architetto del software, e secondo quanto ho detto prima, probabilmente sì.
• Quell'applicazione è verde? Bene, per raggiungere quegli standard di prestazioni, come il tempo di caricamento in millisecondi, probabilmente ho utilizzato molte risorse preziose, costose e ad alta emissione di carbonio. Un giocatore di fantacalcio può permettersi di aspettare un caricamento della pagina più lento? Sì! Perché quella funzionalità non è critica e non impatta su nessun fattore economico perché la tua concorrenza ha prestazioni simili. Detto questo, possiamo finalmente affermare che la mia applicazione di fantacalcio non è green.

Per determinare se un'applicazione funziona in modo ecologico e partendo dal presupposto che l'app sia ottimizzata in termini di costi e risorse, un ingegnere del software sostenibile deve considerare 3 fattori cruciali:

1. Metriche di utilizzo delle risorse
2. Metriche dell'esperienza utente (misurate principalmente dal tempo di attesa del servizio con un carico utente medio)
3. Scenari di distribuzione, che dividono diversi tipi di applicazioni in una serie di categorie. Ognuna di queste categorie può riguardare alcuni standard di performance tipici di quell'obiettivo aziendale.

Senza nessuno di questi 3 elementi, non è possibile determinare se un'applicazione è verde!

Scenari di distribuzione e categorizzazione delle app

Cominciamo con un esercizio di stile (per niente facile…). Distribuiamo tutte le applicazioni in una serie di bucket che rappresentano le categorie software e, di conseguenza, in una pletora di scenari aziendali:

App per la produttività dell'ufficio: l'app più famosa in questa categoria potrebbe essere un server di posta, come Microsoft Exchange. Di solito, queste applicazioni richiedono un'elevata capacità di archiviazione e un elevato utilizzo della CPU. Generano un volume elevato di "accesso utente" con importanti metriche SLA da considerare.

Gestione dei contenuti: in questa categoria puoi trovare principalmente software CRM e CMS, come Microsoft SharePoint. I requisiti di risorse sono come la categoria precedente, ma con un consumo di CPU inferiore.

App di amministrazione aziendale: questo è il bucket in cui ricadono le classiche applicazioni LOB (Line-of-Business), come software per le risorse umane, software di contabilità e software di gestione finanziaria. La maggior parte delle volte, un'applicazione LOB ha esigenze di archiviazione medio\basse e un basso utilizzo della CPU, poiché influisce su un numero limitato di utenti (i dipendenti).

App di utilità: le app tipiche che possono rientrare in questa categoria sono l'archiviazione di file e software di collaborazione e condivisione di risorse come Microsoft OneDrive. Spesso hanno bisogno di spazio di archiviazione elevato, ma hanno SLA attesi medio\bassi.

Digital Media Asset Management (DAM) \ Servizi di streaming: Netflix, Amazon Prime e Google Play sono le piattaforme più famose in questa categoria. Il software che esegue questi servizi consuma molto risorse e rete e, a causa dell'elevata concorrenza nel segmento, deve offrire un'esperienza utente molto rapida con un caricamento della pagina quasi in tempo reale.

Possiamo continuare a classificare le applicazioni definendo molti altri bucket, come applicazioni AI, servizi cognitivi, BOT, app di Machine Learning, Edge Computing e soluzioni IoT, ma non è lo scopo di questo documento definirli tutti (potrei fare un tuffo nel mio post successivo però).

Quando questa classificazione sarà completata nel dettaglio, potremo tracciare una rappresentazione matriciale del consumo medio di risorse per ogni categoria di applicazione, più l'importante colonna che rappresenta l'impatto sulla User Experience misurato in "tempo di attesa massimo previsto" per il caricamento della pagina del servizio:

Ora possiamo finalmente concentrarci su quelle che possono essere le attività relative all'ESS:

Immagina un sistema complesso, probabilmente basato su funzionalità di apprendimento automatico, che si occupi di tutte quelle metriche. Eventuali variazioni su tali KPI possono generare un avviso o un avviso in una dashboard dedicata e ognuno di questi dovrebbe essere correlato alle azioni.

Tieni presente che nel mondo SSE un degrado della UX potrebbe non essere necessariamente una cattiva notizia, anche se è molto importante rimanere entro determinati limiti di usabilità se non vuoi che i tuoi utenti lascino l'app e migrino alla concorrenza.

In letteratura è facile trovare alcune raccomandazioni di base sul tempo di risposta: Jakob Nielsen nel 1993 ha delineato 3 metriche principali per il tempo di risposta. Sebbene questo riepilogo possa sembrare obsoleto, le metriche sono ancora significative in quanto sono generalmente basate sul modo in cui l'attenzione umana si comporta:

0,1 secondo – il limite oltre il quale la reazione del sistema non sembra istantanea.

1 secondo - quando l'utente noterà il ritardo, ma senza flusso di pensiero interrotto.

10 secondi - quando l'attenzione dell'utente è completamente persa.

Di solito, un utente normale può sentirsi molto turbato quando raggiunge questa soglia di 10 secondi, poiché circa il 40% degli utenti abbandonerà immediatamente l'applicazione. Vale a dire che implementare le regole da mettere in atto quando si raccolgono le metriche SSE, non è un lavoro facile. Nei miei prossimi post, li approfondiremo in dettaglio, specificando quando generare avvisi e avvisi e le possibili azioni correlate con lo scopo di mantenere un'app green.

Fabrizio Morando