Green IT is niet mijn probleem - of toch wel?

Pleidooi voor meer aandacht voor de impact van software op energiegebruik

Als het gaat om het verduurzamen van ICT wordt tot nu toe vooral gekeken naar datacenters en IT-hardware. Maar al te gemakkelijk wordt vergeten dat ook de programmatuur die gebruik maakt van deze hardware-omgevingen een grote impact heeft op energiegebruik en - bijvoorbeeld - uitstoot van CO2. Het wordt tijd dat ook softwareontwikkelaars en IT-architecten hun verantwoordelijkheid nemen als het om Green IT gaat, meent Marcel den Hartog.

Wat iemand ook van de huidige discussies over CO2-uitstoot, stikstofproblemen, energietransitie of welke andere milieu­discussies dan ook mag vinden, als IT-industrie moeten we ernstig rekening houden met deze sentimenten. Niet op cijfers gebaseerde of oude uitspraken als ‘één Google search kost net zo veel als een gloeilamp die 17 seconden brandt’ of ‘één Google search kost net zo veel als een autorit van 65 meter’, worden makkelijk gedaan en datacenters krijgen al snel het stempel van energievreters en CO2-uitstoters. Met 77,681 Google searches en 79,917GB aan internet-verkeer per seconde kun je op die manier alles een dramatische draai geven. Zet er een plaatje naast van een enorm datacenter met veel flikkerende lampjes, enkele tienduizenden servers en heel veel netwerkapparatuur om alles met de buitenwereld te verbinden en iedereen begrijpt dat het niet lang meer gaat duren voordat wij - als IT-industrie - dezelfde stempels opgedrukt krijgen als raffinaderijen, varkensboeren, luchthavens en dieselmotoren.

Door een dreigend tekort aan capaciteit van het elektriciteits­netwerk, zijn de meeste datacenters - met name de bedrijven in de Randstad - zich hiervan bewust en zien we dat er aan allerlei creatieve oplossingen gewerkt wordt om te voorkomen dat het energieverbruik uit de hand gaat lopen. Maar tot mijn verbazing gaat het hier vooral over hardware-oplossingen en blijft de rol van de software - en daarmee de rol van de software architect, de ontwikkelaar/programmeur, de database administrator en dergelijke - onderbelicht.

Al jaren zien we dat de capaciteit van de processoren, de snelheid van solid state disks (SSD) en de hoeveelheid geheugen in onze laptops en werkstations enorm toeneemt. Verrassend genoeg starten programma’s en processen nog steeds net zo snel op als drie, vijf of zeven jaar geleden, afgezien van de toename in snelheid die we van SSD’s mogen verwachten. Tegelijkertijd zien we de omvang van de applicaties en apps die we gebruiken enorm toenemen. Voorbeeld: op mijn eigen werkstation staat een PDF Reader die (volgens opgave) 486MB in beslag neemt. Naast een alternatief van 2MB. Ik zie ook een video editor van 759MB en een alternatief hiervoor van 198MB. Natuurlijk is dit commerciële software op een privé-werkstation, maar mijn ervaring met in-house geschreven of gekochte applicaties voor professioneel gebruik is niet anders. Ik zie een aantal belangrijke oorzaken:

Libraries. De simpelste programmatuur wordt, vaak door het opnemen van allerlei libraries (je weet immers maar nooit waar die goed voor kunnen zijn…), al honderden megabytes groot. Megabytes die gecompileerd, geladen en getest moeten worden. MB’s die van development naar testafdeling naar acceptatie naar productie verscheept moeten worden. Megabytes die in het geheugen geladen worden van servers en werkstations en megabytes die door de netwerkkabels gepompt moeten worden. Natuurlijk wordt er ‘gecached’ en gevirtualiseerd, maar het blijven megabytes en gigabytes. En met honderden gebruikers worden gigabytes uiteindelijk gewoon terabytes…

Agile Development. Door de toenemende druk om iedere dag, iedere week of iedere twee weken een nieuwe versie van een softwareprogramma te lanceren, moeten er concessies gedaan worden. En tuning hoort daar helaas bij. Agile gaat mijns inziens voorbij aan het feit dat een grote applicatie zich bijna gedraagt als een organisme op het moment dat hij in productie genomen wordt. Plotseling zijn er zoveel randverschijnselen die het gedrag van de applicatie beïnvloeden, dat bottlenecks die eerst niet zichtbaar waren plotseling een enorme impact hebben. Databases met miljoenen rows, duizenden gebruikers, netwerk latency, applicaties die via API’s met onze applicatie communiceren - allemaal hebben ze impact op het gedrag van onze applicatie. Maar tegen de tijd dat we de twee grootste problemen hebben opgelost en toe zijn aan de tien kleinere die ook zorgen voor meer geheugengebruik of een toename in dataverkeer, is er weer een nieuwe versie met nieuwe problemen. We krijgen zelden of nooit de kans om het ‘organisme’ als geheel een tijdje te tunen en te stroomlijnen. De ‘hardware jongens’ lossen het wel op. Servertje erbij, beetje geheugen en ‘gaan met die banaan’.

Het wachten door slechte performance blijft echter bestaan, de gebruikers wachten alleen maar een beetje sneller.

Logbestanden, de ‘verzekeringspolis’ van veel beheerders. Dankzij logbestanden kunnen we na een database crash alles veilig terugzetten. Dankzij log-bestanden weten we welke superuser de back-up heeft gestopt omdat hij iets eerder naar huis moest en welke secretaresse de user-id/password combinatie van haar manager gebruikt om facturen te boeken én te betalen. Maar hoeveel logbestanden hebben we eigenlijk? En wat gebruiken we daar nu eigenlijk van? Zijn die 200Gb grote logbestanden die per uur gegenereerd worden nu echt nodig? Of kunnen we dit misschien halveren? En ik hoor mensen denken: ‘200Gb?! No way!’. Geloof me, het is in 75% van de bedrijven veel meer dan dat (zie kader).

De oplossing(en)

Ik denk dat iedereen zich in bovenstaande herkent. Maar welke stappen moeten we nemen om ons steentje bij te dragen? Allereerst zullen de enterprise IT-architecten zich moeten verdiepen in de materie. Hoe kunnen we de business blijven ondersteunen en hoe kunnen we dit verbeteren zonder dat we volgend jaar wéér extra megawatts moeten reserveren bij onze provider? Moet er een extra stap in ons agile-proces gebouwd worden om stabielere, efficiëntere en snellere releases te bouwen? Welke logbestanden zijn er nou echt nodig? Hebben we tools nodig om baselines te zetten en de performance te meten? En als we die tools al hebben, worden die dan ook echt gebruikt? Soms hoor ik architecten met trots zeggen dat zij geen technische achtergrond hebben, maar dit ontslaat hen er niet van om over deze technische zaken na te denken. ‘Het milieu’ staat bij veel bedrijven hoog op de agenda en er is geen enkele reden waarom IT (en dus de architecten) daar géén belangrijke rol in moet spelen.

Maar ook iedere programmeur, DBA en beheerder zal zich achter haar of zijn oren moeten krabben en zich realiseren dat een efficiënt algoritme, een slim stukje code of het aan- en uitzetten van ‘energy savings’ op de servers al snel net zo veel (milieu-)effect heeft als fietsen naar kantoor in plaats van met de auto of het openbaar vervoer.

Voorbeeld uit de praktijk

Voor de sceptici onder ons een klein voorbeeldje (uit de praktijk). Een inefficiënte JAVA SQL call naar een database om via de webpagina een lijst te tonen, duurt ongeveer 0,4 seconden. Dit is 2x langer dan een geoptimaliseerd SQL statement (0,2 sec). Naarmate de database groeit loopt dit iedere week op met ongeveer 0,01 seconde, terwijl het geoptimaliseerde SQL statement deze extra 0,01 seconde pas na 4 weken laat zien. Na 12 weken is de wachttijd 0,52 seconden of (geoptimaliseerd) 0,23 seconden. Iedereen die wel eens SQL statements heeft geanalyseerd, weet dat dit absoluut geen overdreven voorbeeld is. Vermenigvuldig dit nu eens met 100 requests per minuut en we praten meteen al over serieuze getallen.Als laatste moeten we natuurlijk gewoon een SLA (service level agreement) afspreken met onze providers. Als we een nieuwe versie uitrollen die aanzienlijk minder efficiënt (of juist efficiënter) is, dan moeten we ook daar de financiële na- en voordelen van zien. En waarom daar geen bonus van maken voor het team dat de grootste sprongen heeft gemaakt?

Bewustwording

Het belangrijkste is, dat we ons bewust worden van de rol die we spelen. Hoe goed ben je bezig als je alle gloeilampen thuis vervangt door energiezuinige led-verlichting en je tegelijkertijd een nieuwe versie van je app of applicatie aanbiedt die op jaarbasis een veelvoud aan extra energie verbruikt? Zelfs de app op je mobiele telefoon moet geen gedrocht worden waardoor gebruikers (jij dus) een kwartier of half uur eerder aan de oplader moeten. Toch?

Marcel den Hartog werkte dertig jaar voor een grote aanbieder van enterprise software