TestAutomatisering & PerformanceTesten

Performance en de cloud

Eén van de meest genoemde voordelen van de cloud is de in theorie oneindige schaalbaarheid. Zo zou het niet meer nodig zijn om als organisatie veel reservecapaciteit in te richten om pieken op te vangen en de performancerisico’s zouden helemaal verdwijnen. Maar is dat wel altijd zo? Wanneer wel, wanneer niet? Duidelijk is, dat wanneer de cloud een rol speelt, dit zeker impact heeft op het aspect performance. Sommige risico’s verdwijnen, sommige veranderen en andere risico’s ontstaan juist. In deze blog sta ik hier graag bij stil. Ik zal aan de hand van een aantal performance aspecten de verschillende cloud toepassingen langslopen, waarbij ik een helder beeld schets over de performance risico’s die hierbij verdwijnen, veranderen of juist ontstaan.

Om te beginnen doe ik even een recap van een aantal verschillende cloud toepassingen. Naast dat er allerlei leveranciers zijn, zoals bijvoorbeeld Microsoft met Azure, Amazon met AWS of IBM met IBM cloud, zijn er verschillende mogelijkheden om de cloud te gebruiken. De “XaaS” termen geven de verschillende niveaus aan (zoals IaaS, CaaS, PaaS, FaaS of SaaS). In het kader van dit artikel sta ik vooral stil bij IaaS (Infrastructure as a service) en SaaS (Software as a service). Denk bij IaaS aan componenten (virtuele machines, databases en/of netwerkcomponenten) die zelf beheerd worden. Bij SaaS zijn het systemen die meteen gebruikt kunnen worden zoals bijvoorbeeld Office 365 of Salesforce.

Performancetesten doen we vooral om risico’s af te dekken op het gebied van niet-functionele eisen (non functional requirements) zoals snelheid, stabiliteit en schaalbaarheid. Binnen het ISO 25010 model voor productkwaliteit zijn categorieën terug te vinden die te maken hebben met performance testen.  In het onderstaande plaatje zijn aspecten die je met performance testen kunt afdekken, met rood omrand.

Hieronder licht ik hiervan drie willekeurige aspecten uit om te zien wat de impact van de verschillende cloud toepassingen zijn.

We beginnen met het aspect Capacity binnen de categorie Performance efficiency. Bij een SaaS-oplossing is de leverancier in controle op het gebied van Capacity. Als afnemer/klant van dit product is het niet mogelijk hierop directe invloed uit te oefenen. Als Office 365 traag is vanwege het vele gebruik, kunnen gebruikers er niet zelf voor zorgen dat er meer servers in de lucht komen om de vertraging minder te maken. Wel is het slim om hierop langdurig te monitoren om mogelijke vertragingen inzichtelijk te krijgen. Zo creëer je inzicht in wanneer er vertragingen optreden. Met dit inzicht kan de leverancier goed onderbouwd worden gewezen op vertragingen.
Bij een IaaS oplossing bestaan er mogelijkheden om automatisch (horizontaal) te schalen. Meestal wordt op basis van resourcegebruik bepaald dat er meerdere virtuele machines moeten worden bijgezet. Dit wordt dan zodra het resourcegebruik het toestaat, weer afgebouwd. Een voorbeeld hiervan is “Azure virtual machine scale sets”. Het is wel belangrijk om bij dit soort oplossingen te testen of de applicatie hierop ingericht is en of de gebruikte centrale componenten die niet onder de schaling vallen, hier goed op reageren. Denk hierbij bijvoorbeeld aan een centrale database die alle geschaalde virtuele machines gebruiken.In bovenstaande beschreven SaaS en IaaS oplossingen zien we dat er minder performance-risico zijn dan in traditionele omgevingen, aangezien de schaling door of de leverancier of het systeem geregeld wordt. Wees er wel van bewust dat, wanneer er geen automatische schaling is binnen een IaaS oplossing, het performance-risico op het gebied van Capacity wel degelijk nog bestaat.

Een andere categorie die belangrijk is, is stabiliteit. Hier licht ik het aspect Availability (beschikbaarheid) uit. De definitie van Availability is: ‘de mate waarin een systeem, product of component operationeel en toegankelijk is wanneer men het wil gebruiken’. Denk hierbij aan het beschikbaar zijn van systemen maar ook aan backups/restores, mirrored data, meerdere datacenters, maar ook aan recovery-scenario’s.
Verder moet er net zoals bij niet-cloud systemen ook bij cloud systemen aandacht zijn voor risico’s op het gebied van resiliance, fail-over en back-up & restore. Resiliance (veerkracht) is de mate waarin het systeem bestand is tegen bepaalde mate van onderbreking. Fail-over gaat over de impact van een verstoring. En bij back-up & restore bedoelen we of na het terugzetten van een back-up inderdaad de juiste gegevens beschikbaar zijn.

Afhankelijk van de gekozen oplossing (IaaS of SaaS) wordt dit (deels) door cloudleveranciers opgelost. Bij IaaS geldt dat er vaak ten onrechte uitgegaan wordt dat de cloudleverancier “het wel geregeld heeft”. Let op. Dit is niet een verantwoordelijkheid van de leverancier. Wanneer dit niet goed geregeld is, dan is er grote kans dat dit tot problemen leidt. Bovenstaande risico’s bestaan dus nog bij cloud en dienen dus getest te worden.

Daarnaast speelt de snelheid waarmee het systeem weer beschikbaar komt ook nog een rol. Hierbij kan “infrastructure as code” helpen. Wel moet dan geregeld zijn dat de systeemeigen data ook weer beschikbaar komt. Dit is prima te testen.

Bij een SaaS-oplossing is beschikbaarheid (meestal) wel een verantwoordelijkheid van de leverancier. Het is belangrijk om de afspraken hieromtrent, bijvoorbeeld in een SLA, goed duidelijk te hebben. Door hier zelf op te monitoren kan je vervolgens in de gaten houden of de leverancier dit doet conform afspraak.

Als laatste aspect kijken we naar time behaviour. Dit is de mate waarin transactietijden en doorvoersnelheid van een systeem, tijdens de uitvoer van zijn functies, voldoet aan de wensen.

Bij cloud-based systemen draaien de systemen niet op het eigen netwerk. Het kan zelfs zijn dat de systemen op fysiek grote afstand ‘draaien’ van de interne systemen en doordoor vertragingen (latency) introduceren. Bij IaaS oplossingen zijn de oplossingen vaak complexer: er worden veel verschillende componenten uit verschillende categorieën gebruikt. Vooral bij het gebruik van templates (zoals via de marketplace) worden meer componenten gecreëerd dan in eerste instantie gedacht, denk hierbij aan virtual network-componenten, load balancers, extra firewalls en publieke IP-adressen. Soms ook nog met combinatie met niet alleen infrastructuur componenten maar ook CaaS (containers as a service), FaaS (functions as a service) of PaaS (platform as a service, zoals databases). Uiteindelijk is het wel belangrijk om een goed beeld te hebben of al die componenten samen zorgen voor een goede doorvoersnelheid en acceptabele transactietijden.

Zelfs bij SaaS is het van belang om te controleren of de beloften van de leverancier wel worden waargemaakt.

Een ander belangrijk aspect in de cloud is het kostenaspect. Door allerlei ruime standaardinstellingen van cloudleveranciers is de kans groot dat je meer kosten maakt dan nodig. Het risico dat je (soms exponentioneel) te veel betaald valt prima af te dekken door het doen van performancetesten. Hiermee is het mogelijk om applicaties te tunen zodat minder schaling nodig is, kleinere VM’s in te zetten en andere infrastructuurcomponenten te optimaliseren (zoals loadbalancers). Het gaat in deze blog te ver om hier uitgebreid over te schrijven en maar dit is zeker een interessant onderwerp voor een andere keer.

In deze blog heb ik aan de hand van de drie aspecten capacity, availability en time behaviour stilgestaan bij het feit dat performance risico’s veranderen wanneer er gebruik gemaakt wordt van de cloud. Het is duidelijk dat je met andere ogen moet kijken naar welke risico’s er zijn en hoe je deze het best af kan dekken. Het belang van het kijken naar je niet-functionele requirements en naar performancetesten is dus niet veranderd door de cloud. Wel zorgt het dynamische aspect van de cloud er mogelijk voor dat je zaken anders moet aanpakken.

Ik ben heel benieuwd naar wat jouw ervaringen zijn met betrekking tot performance en de cloud. Mocht je deze willen delen, heel graag! En ook wanneer je vragen hebt over dit blog, of over performance al dan niet in relatie tot cloud, hoor ik graag van je. We hebben een mooie presentatie klaar staan die we graag komen presenteren. Neem contact op via het formulier, vindt mij op LinkedIn of bel even wanneer je dat liever doet.

Dank voor je aandacht!

2 reacties op “Performance en de cloud”

  1. Wim van de Kraats schreef:

    Eén aspect zou ik er uit willen halen en willen onderstrepen en dat is de monitoring en of de monitoring mogelijkheden van een cloud oplossing. Die monitoring is vaak onder belicht in organisaties.
    Op basis van een businesscase gaan bedrijven naar de cloud.
    Gedreven door onder andere (maar niet gelimiteerd tot):
    -time to market
    -cloud zou goedkoper zijn dan on-prem
    -IT is niet iets waar het bedrijf goed in is of in wilt worden
    -Er wordt een hoop werk uit handen genomen wat betreft patching, beveiliging en backups
    -snel op te zetten
    -wijzigingen aan brengen is flexibeler dan in een on-prem omgeving
    -eenduidige code-base en architectuur
    -het bedrijf kan zich (weer) concentreren op waar het goed in is i.p.v. op de IT

    Allemaal legitieme argumenten.
    Eenmaal in de cloud valt de performance vaak tegen en lijken er geen afspraken gemaakt over de op te leveren performance en hoe die geleverde performance gemeten is of wordt.
    Het komt ook nog wel eens voor dat bepaalde oplossingen multicloud of hybride worden opgeleverd waarvan deel-(micro/mini)services hier leven en andere services bij een andere cloud leverancier leven waardoor onderzoek naar performance gerelateerde problemen moeizaam verlopen.

    Door de klant wordt te vaak geaccepteerd dat de cloud leverancier wel opschaalt als de performance tegen valt maar dat inzicht voor de eindklant is er niet. En dat wil je wellicht ook helemaal niet. Je bent namelijk naar de cloud gegaan met het idee en het vertrouwen dat, dat soort pijnpunten door de cloudprovider geruisloos worden opgelost.
    Dat is dus vaak niet het geval. (Althans dat zie ik nog wel eens.)
    Dan begint het circus met het uitzoeken waar de problemen zich manifesteren en moet er gebeld en gemaild worden, cases aangemaakt worden bij meerdere partijen etc. En dan mag je hopen dat het iets is wat snel en makkelijk te pinpointen is. Daar kunnen makkelijk dagen of weken over heen gaan.

    Dus hoewel je het als cloud klant misschien helemaal niet wilt is het toch aan te bevelen om de performance gerelateerde PKI’s heel duidelijk te hebben en deze ook eenduidig te (laten) monitoren. Die informatie moet niet alleen beschikbaar blijven binnen de cloud provider maar toegankelijk gemaakt worden naar de eindgebruikers organisatie. De geleverde performance wordt dan transparant gedeeld tussen cloudprovider(s) en eindgebruikers organisatie.
    Die transparantie zou wat mij betreft niet als argwaan opgevat moeten worden tussen de partijen maar als doel moeten hebben om gezamenlijk een beter en meer performante service neer te zetten voor de eindgebruiker.

    Die transparantie kan geleverd worden door het inrichten van een monitoring oplossing die de verschillende delen bij elkaar kan brengen maar ook de mogelijkheid te behouden om in te zoomen op de deel-services en componenten. De grote monitoring leveranciers kunnen dat vaak wel. Ook in de architectuur van de could oplossing moet hier al over nagedacht worden. In serverless architecturen kan dat nog wel eens een uitdaging zijn.
    Als dat toch niet mogelijk is om een overall dashboard te creëren dan is het noodzakelijk om delen van de geboden service te monitoren en die gegevens te delen tussen de cloudpartijen en eindgebruikers organisatie.

  2. Misha schreef:

    Leuk artikel Marc! in een algemeen begrijpbaar Jip-en-Janneke taal ook nog 🙂
    Ik ben benieuwd wat de overwegingen er waren om dit in het NL de doen: met het Engels zou je zeker een grotere publiek bereiken 🙂
    veel succes en hopelijk meer inhoudelijke reacties dan deze 🙂

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Nieuws

Blijf op de hoogte

Azure DevOps pipeline met Gatling

02/10/2020

In deze blog wordt beschreven hoe je Gatling performance testen in een Azure DevOps pipeline kan hangen.

Gatling simulaties in een executable jar

07/08/2020

Performance testen: Een handleiding voor het produceren van een fat jar uit een gatling framework.

Don’t be a fool, get the right tool!

30/06/2020

Heb jij weleens een keuze gemaakt voor een tool die achteraf gezien toch niet de verstandigste bleek? Helaas een ervaring die veel IT professionals weleens opdoen. En gezien de tools in de moderne ontwikkelomgevingen niet meer aan te slepen zijn, denk ik dat dit nog weleens vaker het geval gaat zijn.. Als testautomatiseerders hebben wij […]

Performance en de cloud

27/05/2020

Eén van de meest genoemde voordelen van de cloud is de in theorie oneindige schaalbaarheid. Zo zou het niet meer nodig zijn om als organisatie veel reservecapaciteit in te richten om pieken op te vangen en de performancerisico’s zouden helemaal verdwijnen. Maar is dat wel altijd zo? Wanneer wel, wanneer niet? Duidelijk is, dat wanneer […]

Ervaringen Performance.Now() 2019

13/12/2019

Ervaringen conferentie PerfNow

Performance test in de pipeline

25/10/2019

In deze blog geef ik kort en bondig neer in welke opzet en met welke tooling ik performancetesten heb geïntegreerd in de pijplijn bij mijn huidige opdracht.

Circle-CI, van code naar webserver met één klik.

13/09/2019

Wanneer je ‘vroeger’ een website had, waren er altijd flink wat handelingen nodig om files via een FTP client op een webserver te krijgen. Vandaag de dag, met behulp van een verscheidenheid aan tooltjes, is dat een fluitje van een cent. Daarnaast krijg je een arsenaal aan mogelijkheden mee als builden, testen, etc.. In deze […]

Een korte intro in data-analyse met R

10/07/2019

Een blog over hoe je met behulp van R grote hoeveelheden data kan analyseren. Een tool dat je helpt bij de analyse van bijvoorbeeld load- en stresstestresultaten.

Installatie Oracle ATS op Windows

28/03/2019

Handleiding over hoe je Oracle ATS installeert op Windows (Versie 13.x of hoger)

Postman API testen in CI

01/02/2019

beschrijving van hoe je jouw Postman collectie laat draaien vanuit Jenkins en hoe je hierbij een praktisch JUnit test report krijgt.

Workshop ‘Stop de Magie!’ bij Qquest

04/12/2018

In het kader van de 4e techday van Qquest heeft Chris met ondersteuning van HenkJaap een workshop gegeven. Basis was de presentatie en demo ‘No more magic’ van Bas en Chris, welke al een groot succes was op de TestAutomationDay en TestNet. Centraal bij het onderwerp ‘No more Magic’ staat het idee dat er bij […]

Visual Regression Testing – Wat is het en wat heb je eraan?

07/11/2018

Visual Regression Testing, of visuele regressie testen, is een categorie van testen die zich focust op het identificeren van visuele wijzigingen tussen iteraties of versies van een website. Dit kan handmatig door schermen of schermafdrukken te vergelijken, maar het is beter herhaalbaar en sneller te testen door dit automatisch te doen. Het mooiste is om deze testen als een […]