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 de website of vindt mij op LinkedIn.
Misha schreef: 2 juni 2020 om 14:14 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 🙂
Wim van de Kraats schreef: 2 juni 2020 om 11:20 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…