Auteur: Bart Knaack ● Bart.Knaack@proftest.nl
Redactie: Eric Spaargaren en Paul Beving
Tijdens het afgelopen najaarsevenement hebben wij, Bob, ‘Iris’ en ik, een oproep gedaan om met ons mee te denken over sustainability als kwaliteitsattribuut en hoe wij daar iets mee kunnen als testers, met een oproep om met ons mee te denken hierover. In deze blog willen we wat dieper op de materie ingaan en jullie uitnodigen om te reageren. Disclaimer: nee, wij zijn ook geen sustainability experts en dus willen we graag de discussie met jullie aangaan. Dit is een eerste aanzet tot gedachtenvorming hierover en geenszins een poging de waarheid te poneren, maar verleiden jullie graag tot discussie.
Reacties graag plaatsen in de commentaarvelden onder deze blog zodat iedereen mee kan lezen.
Sinds het najaarsevenement hebben wij ons wat meer verdiept in de materie rond sustainability en zijn we erachter gekomen dat sustainability over veel meer gaat dan alleen het energieverbruik of de carbon footprint van je app. Sustainability wordt in de algemene zin opgedeeld in drie gebieden: ecologisch, financieel en sociologisch.
Deze drie aandachtsgebieden hebben ieder hun eigen aandachtspunten en er zitten testbare zaken in alle drie. Daarnaast hebben deze aandachtsgebieden ook hun weerslag op de samenleving in het algemeen en daarmee ook op IT als faciliterende factor in brede zin. Dit houdt in dat – net als kwaliteit in het algemeen – sustainability niet iets is dat je ‘er achteraf even in test’; sustainability is een aspect dat alle facetten van de IT raakt en dat je dus ook mee moet nemen in de designfase en misschien nog wel eerder, dus zelfs in de vraag ‘moeten we dit echt wel willen’.
Een veel gekoesterde gedachte is dat sustainability of duurzaamheid niet samen gaat met profitability. Dat is echter een misvatting. Er is niets mis met winstbejag, maar sustainability zet wel kaders waarbinnen je je winstoptimalisatie neerzet.
Als we kijken naar de – testbare – aspecten van sustainability, dan springt een aantal naar voren:
- Efficiency van het product
- Energiegebruik
- Resource usage
- Bandwidth
- Datastorage
- Memory
- Resource usage
- Onderhoudbaarheid van het product
- Inclusie van het product:
- Accessability
- Ease of use
- Portabiliteit van het product
- Browser compatibility
- OS compatibility
- Hardware compatibility
- Interoperabiliteit van het product
Zonder afbreuk te willen doen aan de laatste drie aspecten willen we ons als eerste concentreren op de eerste twee aspecten, de efficiency van product gedurende de complete SDLC en – omdat dit daar direct mee samenhangt – de onderhoudbaarheid van een product.
Efficiëntie in de SDLC van een product
Om sustainability meer ‘te plotten’ op IT en softwareontwikkeling onderscheiden we drie lagen van sustainability:
- Sustainability gedurende het ontwikkelproces;
- Sustainability gedurende de lifetime van het ontwikkelde product;
- Sustainability van het doel van het product.
De eerste twee hangen sterk samen met de SDLC van een IT-systeem, terwijl de derde meer samenhangt met de bedrijfsvoering rond het product. Als testers en IT’ers focussen we voornamelijk op de eerste twee aandachtsgebieden, terwijl het derde oogpunt ook zeker aandacht verdient, misschien daarover meer in een volgende blog of tijdens de eventueel op te richten werkgroep.
Om een houvast te geven aan (het testen van) sustainability in een IT product kijken we naar de verschillende aspecten van de SDLC van een IT product:
- Het ontwerp en de bouw van een product;
- Het gebruik en onderhoud van een product;
- Het afbouwen en decommisionen van een product.
Het ontwerp en de bouw van een product
In de ontwerp- en bouwfase van een product is het ten eerste van belang om op een sustainable manier aan de gang te gaan, maar ook om vooruit te denken over de sustainability van het product tijdens het gebruik en of het afbouwen van een product. Door al tijdens de ontwerpfase deze aspecten mee te nemen, zien we dat sustainability een integraal onderdeel van het product is, in plaats van een afterthought die er aan toegevoegd wordt.
Keuzes die tijdens de ontwerp- en bouwfase aan de orde komen zijn:
- wat voor architectuur wordt gebruikt;
- Infrastructuur en platform keuze;
- Keuze van programmeeromgeving en programmeertaal.
Hierin zien we vaak een ‘trade-off’ tussen gebruiksgemak en efficiëntie. Voorbeeld: Python wordt door velen als een ‘makkelijke’ programmeertaal gezien. De taal heeft als voordelen dat het dynamic typecasting heeft en de overerving van classes wordt deels automatisch gedaan. Echter, uit onderzoek is gebleken, dat de energie consumption van Python (ook door de noodzaak van een runtime engine, aangezien het een geïnterpreteerde taal is) 75 maal hoger ligt dan die van een programmeertaal als C, waarbij de code in executables gecompileerd wordt. Daarmee is ook de performance van een C programma op vergelijkbare hardware vele malen beter dan een Python programma.
Voorbeeld twee: vanwege het argument van scalabililty en flexibiliteit worden cloud solutions steeds vaker gekozen om een robuuste oplossing te genereren met een stabiele performance. Om van deze ‘features’ gebruik te kunnen maken, is het aan te raden om dan gebruik te maken van dynamische oplossingen zoals bijvoorbeeld lambda functions of microservices. Wat we echter te vaak zien, is dat de traditionele oplossingen een-op-een (via een soort lift en shift) in de cloud worden gebracht op (vaak fixed size) virtual machines, waardoor de energie consumptie juist hoger is door de afstand waarover de data heen en weer gestuurd moet worden ten opzichte van lokale computing power.
Het gebruik en onderhoud van een product
Tijdens het gebruik van een product zijn belangrijke factoren als resource consumption van zowel CPU als geheugen van belang. Als een product bijvoorbeeld sterk te maken heeft met piekbelasting wordt de hardware gedimensioneerd op de hoogste belasting. Als een dergelijke belasting slechts enkele malen per jaar voorkomt, dan is het systeem 95% van de tijd zwaar overgedimensioneerd.
Wat we in de huidige markt steeds meer zien, is dat cloud-achtige oplossingen door middel van horizontal of vertical scaling kunnen inspelen op dit soort piekbelastingen, maar ook daar hangt weer een prijskaartje aan en als de scaling niet goed ingericht is, dan wordt de downscaling maar mondjesmaat bereikt (gek hoe cloud providers daar helemaal niet mee zitten…)
Voorbeeld drie: een steeds grotere kostenpost op de energiebalans van een systeem is ook het transport van data. Complete datacentra met het energie verbruik van een kleine stad zijn nodig om de opslag en transport van data te garanderen. Denk maar eens in wat het datatransport is van 10.000 mensen die een Netflix serie bekijken in vergelijking met het bekijken van een analoge uitzending door 10.000 mensen.
Voorbeeld vier: het gebruik van Ledger based netwerken, waarin unmutable transacties kunnen worden vastgelegd (voorbeelden crypto currency zoals Bitcoin) zijn zeer rekenintensieve toepassingen. Het in de lucht houden van een dergelijke network kost anno nu net zoveel als het energieverbruik van een land als Zweden en de verwachting is dat tegen 2050 dit gegroeid is tot het energieverbruik van Zweden, Frankrijk, Duitsland en het Verenigd koninkrijk bij elkaar.
Voorbeeld vijf: institutionele resource consumption. Zelfs als wij als consumenten – wereldwijd – het voor elkaar krijgen om ‘onze’ footprint naar nul te reduceren door zonnepanelen, warmtepompen enzovoort, dan is dat ‘slechts’ 3 procent van de complete CO2-uitstoot. De rest zit in institutioneel energieverbruik, industrie en transport (waarmee niet gezegd is dat we daar niet naar moeten streven [RTE1] ).
Bij een van de grootbanken van Nederland is uit onderzoek gebleken dat 57 procent van de CO2-uitstoot toe te wijzen is aan het IT-landschap en niet kantoorverwarming, verlichting en wat dies meer zij.
Als we kijken naar de onderhoudbaarheid van code, dan zien we dat programmeerstijl vaak een doorslaggevende rol speelt. Programma’s geschreven volgens bijvoorbeeld de SOLID principles [RTE2] maken het vaak makkelijker om uitbreidingen aan een programma te doen zonder dat daar hele stukken code voor herschreven of hertest hoeven te worden. Het nadeel van programmeerstijlen is dat deze vaak niet ‘testbaar’ zijn, maar wel reviewbaar.
Het afbouwen en decomissionen van een product
Wat we zien bij veel vervangingsprojecten waarbij een oud systeem vervangen wordt door een nieuw systeem is dat in veel gevallen het oude systeem niet volledig decommisioned kan worden omdat het nieuwe systeem niet alle functionaliteiten van het oude systeem kan uitvoeren. In plaats van een vervanging wordt het dan een plus plus.
Een ander fenomeen dat zich vaak voordoet, is dat nieuwe systemen nieuwe operating systeem vereisten hebben, waardoor het systeem niet op de – inmiddels verouderde – bestaande hardware kan draaien waardoor aanschaf van nieuwe apparatuur nodig is, terwijl de oude hardware vaak nog niet afgeschreven had hoeven worden.
Ook het overzetten van dat uit oude systemen naar het nieuw gebouwde systeem is niet altijd gewaarborgd, waardoor het noodzakelijk is om – voor raadpleegdoeleinde – het oude systeem nog in de lucht te houden (denk ook aan de bewaar- en inzageplicht die wordt afgedwongen door regulerende partijen.
Wat willen we doen?
Uit bovenstaande voorbeelden en beschouwingen blijkt dat er op heel veel terreinen te winnen valt op het gebied van sustainability en ECO-efficiëntie van software. Graag willen we met jullie de discussie aangaan hoe wij – als testers – daar een zinvolle bijdrage aan kunnen leveren. Wat voor testsoorten zouden we daarvoor kunnen gebruiken? Hoe kunnen we de feedback over sustainability in een dermate vroeg stadium geven, zodat deze ten eerste niet als mosterd na de maaltijd komt en ten tweede kort cyclische feedback loops mogelijk maken (om ook binnen het Agile-gedachte goed te passen).
Op het voorjaarsevenement willen we kijken of er voldoende animo is om een werkgroep in deze richting op te starten.
Reacties graag plaatsen in de commentaarvelden onder deze blog zodat iedereen mee kan lezen.