Applicatieontwikkeling is vanaf nu groen

Er is veel aandacht voor groene ict, maar dan vooral voor het optimaliseren van de technische infrastructuur of bijvoorbeeld het gebruiken van opgewekte warmte voor het verbouwen van paprika’s. Naast besparingen op de technische infrastructuur kunnen er ook besparingen worden behaald door groenere applicaties te ontwikkelen. Dit artikel gaat over het belang van groene applicatieontwikkeling en stelt het gebruikt van energielabels voor.

Ict is een relatief nieuwe business als dit wordt vergeleken met productie van goederen of het bouwen van huizen. Een computer met besturingssysteem en tekstverwerker kan al wel gezien worden als gemeengoed, toch is dat niet voor alle applicaties en diensten het geval. In het verleden was er vooral aandacht voor de functionele eisen aan een computerprogramma. Recent lijkt er echter veel aandacht te zijn voor speciale eisen, die ook wel non-functionals genoemd worden. Voor mobiele apparaten is usability, batterijduur en snelheid belangrijker dan de functionaliteit die een apparaat biedt. Immers, is het vanwege de functies dat de iPhone zo populair is, of vanwege de goede usability? Het gemis aan functionaliteit wordt vaak aangevuld door het kopen van een app. Dus het lijkt erop dat doordat ict meer gemeengoed wordt er meer aandacht komt voor de speciale eisen en minder voor de functionele eisen. Dit is omdat de applicaties allemaal dezelfde functies leveren, althans zo ervaart de gebruiker het. Laten we verder inzoomen op twee belangrijke elementen: batterijduur en applicatieperformance.

Performancemetingen

Performancemetingen van applicaties zijn gebruikelijk voor kritieke business applicaties en webapplicaties. Gedurende een performancemeting worden gebruikers gesimuleerd en het gedrag van de applicatie geanalyseerd. Het doelaantal gebruikers is bepaald op basis van de huidige productieload of op basis van een verwacht gebruik. Dit soort performancemetingen is specifiek voor het soort applicatie en momenteel worden verschillende applicaties weinig met elkaar vergeleken.

Tijdens een performancemeting worden er bottlenecks gevonden, maar als er een bottleneck wordt gevonden is er vaak iemand (de manager) die vraagt of de infrastructuur of de applicatie het probleem vormt. Natuurlijk omdat er verschillende mensen zijn die dit dan moeten oplossen. Maar dit is een moeilijke vraag om te beantwoorden, omdat er geen onafhankelijke referentiegetallen voor applicaties zijn.

Voor hardware performance zijn er vuistregels, zoals 120 i/o's per fysieke disk, of een bepaalde maximum netwerkbandbreedte. Voor applicaties bestaan deze getallen niet. Er zijn geen vuistregels voor de duur van een conversieroutine, van bijvoorbeeld een XML-bestand. Daarom is het zo dat een inefficiënte conversieroutine bijvoorbeeld wel veel cpu verbruikt, maar het is onduidelijk of dit beter kan.

Met enige moeite moet het wel lukken om referentiegetallen op te stellen. Zo kan voor een bepaald type routine, of aantal gebruikers dat bediend wordt, of aantal service requests toch wel iets gezegd worden. Op dit moment richt een performancemeting zich op een doelaantal gebruikers. Dit aantal kan worden gezien als een soort absolute waarde. Bijvoorbeeld als we een webapplicatie hebben die omvalt als er vijfduizend gebruikers tegelijk gebruik van proberen te maken, maar nog wel werkt met vierduizend gebruikers. Als de technische infrastructuur bestaat uit vier front-end servers en die bereiken hun piek op cpu-gebied met vijfduizend gebruikers. Dan kan gesteld worden dat de applicatie in staat is om duixend gebruikers/server af te handelen. Het cpu-verbruik kan eenvoudig worden vergeleken met andere webapplicaties. Als duizend gebruikers per server dan ook nog eens gesteld wordt als redelijk, dan volgt daaruit dat vijfhonderd gebruikers per server inefficiënt is. Je kunt dan stellen dat de applicatie eerst verder verbeterd moet worden in plaats van extra hardware toe te voegen.

Momenteel wordt er meestal eerst gekeken naar het toevoegen van hardware voor het oplossen van performanceproblemen. Dit heeft grote gevolgen voor beheer en natuurlijk ook stroomkosten. En dat is waar batterijduur en performance bij elkaar komen.

Energielabels voor applicaties

Nu applicaties gekoppeld kunnen worden aan servers en elektriciteit, kunnen deze applicaties ook eenvoudig met elkaar gaan vergeleken worden. Binnen de Europese Unie is er regelgeving die vereist dat op witgoed, lampen, auto's, en recent ook huizen een energielabel wordt geplaatst.
Natuurlijk kan er veel over deze labels worden gezegd, zoals dat ze door bedrijven worden gebruikt als marketing instrument, of dat de classificatie onjuist is. In ieder geval doen ze ook iets goed. Meerdere technische gegevens worden gecombineerd in één classificatie tussen de A en G. Deze classificatie wordt begrepen door iedereen en er kan eenvoudig regelgeving (zoals de sluptax) aan verbonden worden. Zo zijn er bedrijven die het niet toestaan om auto's te leasen uit een andere categorie dan A of B.

Met een energielabel voor applicaties kan de aandacht uitgaan naar efficiënt gebruik van middelen in plaats van toevoegen van hardware (en toevoegen van complexiteit). Met een energielabel kunnen we applicaties vergelijken voor gebruik in de cloud, op onze telefoon, laptop of de normale computer. Voor al deze bestemmingen is het belangrijk om het laagste energieverbruik en tegelijk de hoogste performance te hebben. Applicaties in de cloud gaan zelfs verder omdat daar de kosten vaak direct gekoppeld zijn aan het verbruik. Dus laten we een energielabel voor applicaties introduceren, dan kan iedereen computerapplicaties vergelijken op energieverbruik.