Er koden grønn?

Grønn programvare er designet for å minimere karbonutslipp gjennom hele livssyklusen. Dette inkluderer effektiv kode, optimal maskinvareutnyttelse og bevissthet rundt energikilder. Et helhetlig perspektiv er avgjørende, hvor operasjonell effektivitet og karbonmåling bidrar til grønnere løsninger. Selv i land med fornybare energikilder er energieffektivitet kritisk for å støtte samfunnet i overgangen til nullutslippsløsninger. (Ingressen er generert av ChatGPT med innholdet i artikkelen som input)

Hva er egentlig grønn programvare?

Svaret på det var ikke så lett å finne som man skulle tro. Grønn - eller bærekraftig - programvare er, i følge Green Software Foundation: (https://greensoftware.foundation), "software that causes minimal emissions of carbon when its run".

Det er en enkel - nesten for enkel - definisjon.
Dette betyr jo i sin ytterste konsekvens at så lenge programmene eksekverer på maskinvare som bare kjører på fornybar strøm (evt. kjernekraft) kan koden være så ineffektiv og ressurskrevende den bare vil. 

Her trengs et par postulater i tillegg.

"Grønn programvare er designet for å kreve mindre energi og færre maksinvare-enheter pr. utførte jobb"
"Grønn programvare tilstreber en dynamisk tilpasning til tidsperioder og geografiske lokasjoner hvor elektrisiteten produseres med et minimum av utslipp av mijøgasser"

Aha! Så her må altså både hardware og den totale energiforsyning inn i ligningen, siden ingen programmer kjører uten maskinvare. 

For å få et totalt bilde av hvordan programvareutviklingen påvirker miljøet, eller utslipp av miljøgasser for å være mer spesifikk, må vi vurdere programvarens livssyklus, og kjenne hele infrastrukturen fra CPU-sykler til brukerenhet. 

Ja, det blir omfattende, men det er nødvendig for å ta kontroll med utslipp av klimagasser forårsaket av bruken av programvare. 

Utvikling av effektiv kode

Grønn programvare starter vel med kodingen? Hva som er effektiv kode oppfattes svært forskjellig ut fra hvilken kontekst programmet utvikles i. Når vi snakker om grønn programvare blir definisjonen litt smalere: Utslipp av miljøgasser skal reduseres til et minimum som følge av programmets bruk i hele dets levetid.

Vi er brått helt nede på målsetninger om å redusere antall CPU-sykler koden krever for å kjøre - noe som ikke står veldig høyt på prioriteringslista eller i kravspekken for de fleste prosjekter. Tidsaspektet, funksjonalitet, APIer og tilgjengelige kode for gjenbruk oppfattes som viktigere enn å redusere strømforbruket i maskinvaren. I tillegg er utviklernes produktivitet selvsagt svært viktig for bedriftens lønnsomhet. 

Å skrive alt i assembler for å gjøre programvaren optimal for maskinvaren den skal kjøre på er stor sett helt utelukket. Å bytte fra f.eks Python til C++ for å oppnå mer energi-gjerrig eksekverbar kode kan være krevende nok i et prosjekt hvor man allerede har en stram tidslinje.

Hvordan man skriver koden for å gjøre programmet "grønt" må bestemmes  i hvert enkelt utviklings-team og i hvert enkelt tilfelle. 

Det finnes svært mange tiltak som kan settes i verk for å gjøre koden mer effektiv når det gjelder krav til HW og strømforbruk. Her er utviklingsmiljøet selv best i stand til å navigere gjennom de forventede effektene av tilgjengelige verktøy, metoder og språk. Dette ligger langt inne i den tekniske sfæren, og håndteres best der.

Jeg vil altså ikke forsøke å rangere eller trekke fram noen alternativer framfor andre, men vil påstå at dersom tilstrebelsene for å generere grønn programvare går ut over produktiviteten til utviklerne eller forsinker prosjektet, så blir det ikke gjort.

Det som er sikkert er at dette blir viktigere i tiden framover, og at kravene til å redusere utslipp gjennom måten sofware utvikles på vil bli tydeligere og sterkere enn de er i dag.

Operasjonelt

Nå beveger vi oss over i fasen hvor produktet er lansert og i bruk. Operasjonell effektivitet handler om å oppnå ønsket  leveranse og funksjonalitet ved bruk av færrest mulig ressurser. Den viktigste parameteren å ha kontroll på er utnyttelsesgraden på maskinvaren som eksekverer koden. På dette feltet er de hyperskalerbare skyplattformene uslåelige. Maskinvare i store datasentre i skyen kan typisk oppnå mer enn 65% utnyttelsesgrad, mot 10% - 20% i lokale Private Clouds.

Plattform, språk og metodikk som klargjør programmet for Public Clouds bør derfor være et opplagt valg for grønn programvare. Også valg av serverless programvare i skyen ligger i samme kategori, og gir høy utnyttelsesgrad.

I tillegg til innebygget høy utnyttelsesgrad i  skyplattformene er det også mulighet for egne initiativer for å øke effektiviteten ytterligere. Her er noen av tiltakene som bør vurderes:

-Unngå overprovisjonering
-Fjerne unødig redundans
-Benytte autoskalering
-Unngå Always-On der hvor det ikke er absolutt påkrevet
-Bruk av spot instance/preemptible instances 

Men om man allerede kjører i et on-prem miljø kan utnyttelsesgraden fortsatt forbedres ved hjelp av noen av de samme teknikkene som på skyplattformene. For eksempel virtualisering og multi-tenant plattformer. 

Utslipp - Carbon awareness

Når koden er effektivisert, og utnyttelsesgraden for maskinvaren er optimalisert, er det neste steget å sette fokus på å unngå å bruke energi som ikke er grønn eller fornybar. Som nevnt i artikkelen Trening gjør AI-mester - men vi må skynde oss, er de store skyleverandørene flinke til å velge fornybar enegi. Det er likevel en rekke tiltak  hver enkelt kan sette i verk for å redusere utslippene, samt redusere energiforbruket generelt.

-Jobber som ikke er tidskritiske kan fordeles ut i tid og kjøres i perioder der forbruk av fossil kraft for å generere elektrisiteten i kraftnettet er lav. 

-Kvaliteten på tjenestene kan reduseres når utslippene av miljøgasser for å produsere elektrisitet i kraftnettet som forsyner datasenteret du kjører dine programmer i er høyt.

-De mest tidskritiske og “Always-on”-jobbene som alltid må kjøre, uansett grønn energi eller ikke, bør være  kodet så effektivt som mulig.

-Ingen jobber settes til høyere prioritet enn de faktisk trenger.

-Hvis mulig, flyttes kalkulasjoner til brukerens enhet for å redusere nettverkstrafikk.

-Prekalkulering og caching av CPU/GPU-intensive beregninger kjøres på forhånd - på tidspunkter hvor grønn energi er tilgjengelig.

For at tiltakene skal ha god effekt må vi vite når strømmen er grønn, og når den ikke er det. Strømnettet er en utrolig komplisert sak, så her trengs det gode verktøy.

Britene kan f.eks finne 96-timers forecast for karbonintensitet per region i UK her: https://carbonintensity.org.uk

Karbonavtrykk ved produksjonen, og levetiden på personlige enheter.

For å se det totale bildet av grønn programvare må også avtrykket av miljøgasser under produksjon av enhetene tas med. Ingen programmer når fram til brukerne uten å involvere enheter som f.eks PC'er, laptop'er nettbrett, smarttelefoner og smart TV. Det viser seg at karbonavtrykket fra produksjonen er langt større en avtrykket av energiforbruket mens enheten er i bruk. 

Selve produksjonen av enhetene får hardwareleverandørene ta seg av, men programvareleverandørene kan bedre denne situasjonen ved å bidra til å forlenge levetiden på enhetene. Dette gjøres ved å unngå å implementere ny funksjonalitet på en måte som framskynder behovet for å oppgradere HW - altså kjøpe ny enhet.

I et net zero-scenario vil enhetene måtte kunne leve mye lenger. Operativsystemene for enhetene har kommet et godt stykke på vei for å støtte dette. Grønn programvare må gå ennå lenger.

Maskinlæring og kunstig intelligens

Kunstig intelligens integreres i flere og flere software-produkter. Maskinlæring krever svært mye datakraft og er derfor en potensiell pådriver til økt karbonavtrykk dersom treningen foregår mens elektrisiteten produseres av fossilt brennstoff. Faktisk er energibehovet til AI/ML så stort at kjernekraft virker pr. d.d. som eneste mulighet til å møte behovet.

Denne situasjonen gjør det bare ennå mer aktuelt å anvende metoder for å redusere energiforbruket knyttet til programvare.

Ved å redusere størrelsen på modellene kan man både gjennomføre treningen raskere, og redusere strømforbruket i datasenteret. Dette betyr ikke bare raskere "time to market" og sparte kostnader, men også potensielt redusert karbonavtrykk. 

Teknikkene for å redusere størrelsen på datamodellene, som for eksempel pruning, compression, distillation og quantization, er allerede kjent innen databehandling, men blir ennå viktigere framover.

Å redusere størrelsen er ikke eneste tiltak. Trening av modellene er sjeldent ekstremt tidskritisk og kan derfor kjøres på tidspunkter som er gunstige for å holde fotavtrykket nede. Bruk av pre-trained modeller vil også kunne bidra tli dette.

Måling og monitorering av karbonintesitet

Kan det ikke måles blir det ikke gjort. Så enkelt er det faktisk. I en perfekt verden ville hvert enkelt tiltak innen grønn programvareutvikling hatt en kvantifisert og dokumentert effekt på karbonavtrykket, slik at effekten kunne måles. Slik er det ikke. Ei heller gjelder dette enhetene vi kjøper i butikken.

Først og fremst er det strømforbruket i seg selv vi må måle. Dersom man har tilgang til maskinvaren som kjører programmet kan man instrumentere dette og få ut data. Dersom programmet kjører i en hyperskalerbar sky er det leverandørens rapporteringsverktøy som gjelder. 

N¨år du vet hvor mye strøm programvaren forbruker, og hvor strømmen kommer fra, trenger du å måle karbonavtrykket. 

Den perfekte løsningen er selvfølgelig en sanntidsmåling av karbonutslipp forårsaket av den enkelte programvares bruk og eksekvering.  Denne løsningen finnes ikke i dag, men karbonintensitet globalt og regionalt rapporteres både historisk, real time og som prognoser av f.eks disse organisasjonene: WattTime API (https://watttime.org) og Electricity Maps (https://www.electricitymaps.com). 

Oppsummert

Etter mitt lille dykk i materien om grønn programvare har jeg lært at det er mange innfallsvinkler til hva dette dreier seg om. En av grunnenene til at det ikke framstår som èn tydelig strategi og metodikk er nok at det som skjer i programvaren har innvirkninger på så utrolig mange forskjellige områder. Kravene til programvaren spenner veldig vidt, og endrer seg gjennom livssyklusen.

The Green Software Maturity Matrix er et verktøy for å bevege seg mot målet.  Utvikler du eller organisasjonen din programvare kan du finne verktøyet her:  https://maturity-matrix.greensoftware.foundation. Den tror jeg må bli tema for neste blogginnlegg om grønn programvare.

Men en ting er helt sikkert: For å nå målet - "software that causes minimal emissions of carbon when its run" - raskest mulig, kan man ikke starte med å skrive om koden for å bli mer CPU-effektiv. Hvor, når og hvordan programmene kjører vil ha mye større effekt på forbruket - og dermed utslippet.

Og helt til slutt: selv om det norske kraftnettet er 100% fornybart er det ingen unnskyldning for ikke å utvikle og operere programvaretjenestene på en mest mulig energieffektiv måte. 

Alle bransjer må bidra til å muliggjøre elektrifiseringen av samfunnet. Energimangelen er allerede et faktum.

Les også:
Trening gjør AI-mester - men vi må skynde oss
Er skytjenestene grønne?