Met de snel toenemende interesse in cloud computing, is schaalbaarheid een thema dat extra aandacht verdient. Gebruikers en organisaties verwachten dat hun websites en cloud-applicaties altijd optimaal functioneren, onder alle omstandigheden.
Er wordt gedacht dat cloud-applicaties beter blijven reageren bij een zware belasting. Een cloud-applicatie of website die bij piekbelasting traag reageert – of soms zelfs helemaal niet beschikbaar is – wordt door gebruikers niet geaccepteerd. Hoge prestaties zijn echter niet vanzelfsprekend.
Naarmate het aantal gebruikers groeit en de complexiteit van cloud-oplossingen toeneemt, zie je in de praktijk dat veel websites niet in staat zijn om de gewenste snelheid te blijven bieden bij piekbelastingen. De cloud wordt door veel mensen gezien als een soort wondermiddel. Geen hardware investeringen, gemakkelijk in te zetten, het beheer wordt verzorgd, kortom: ‘alles gaat vanzelf’. Maar zo eenvoudig is het natuurlijk niet. Bij het ontwerp van cloud-diensten en websites – en vooral bij de keuze voor de achterliggende architectuur – moet heel goed worden nagedacht over de doelstellingen en de eisen. En dat gaat veel verder dan alleen de daadwerkelijke business functionaliteit.
Schaalbaarheid is een factor waar terdege voor gepland en ontworpen moet worden. Zo niet, is het wachten op problemen. We hebben de afgelopen jaren diverse keren in de media kunnen lezen over groots opgezette websites (bijvoorbeeld van evenementen, kaartverkoop voor popconcerten, etc.) die binnen no-time onbereikbaar werden door het grote aantal gelijktijdige bezoekers. Zoiets kost omzet en zorgt voor imagoschade.
Wat is ‘schaalbaarheid’
Maar wat bedoelen we eigenlijk met ‘schaalbaarheid’? Schaalbaarheid is het vermogen van een systeem, een netwerk of een proces om een groeiende werklast efficiënt te kunnen verwerken of het vermogen om uit te breiden. Het kan bijvoorbeeld staan voor het vermogen van een systeem om de algehele doorvoersnelheid te vergroten door de inzet van extra hardwaremiddelen. Dit betekent dat schaalbaarheid en prestaties in feite twee verschillende kenmerken zijn. Schaalbaarheid is het vermogen van een systeem om de verwerkingscapaciteit – bij voorkeur automatisch – te vergroten wanneer de werklast toeneemt. En dat is een van de grootste uitdagingen bij het ontwerpen en bouwen van online schaalbare cloud-oplossingen.
Bij schaalbaarheid zijn er in principe twee varianten: bij scale-up gaat het meestal om het inzetten van zwaardere of nieuwere servers. De tegenhanger daarvan is scale-out. Hierbij wordt de verwerkingscapaciteit vergroot door de werklast te verdelen over meerdere systemen. Deze clustering maakt het mogelijk om applicaties in parallel te draaien op meerdere servers (cluster nodes). Daarbij wordt de werklast verdeeld over meerdere servers en zelfs wanneer één van de servers om welke reden dan ook uitvalt, blijft de applicatie beschikbaar via de overige nodes van het cluster.
Daarom is het dan ook zeer aan te raden om voor belangrijke applicaties minimaal twee servers te gebruiken. De keuze voor scale-up of scale out hangt sterk af van het soort applicatie. Het is echter niet altijd mogelijk om een bestaande webapplicatie op zomaar een applicatie servercluster te draaien om zo de schaalbaarheid en beschikbaarheid van het systeem te verhogen. De webapplicatie moet ontworpen zijn met het oog op deze schaalbaarheid en voorbereid zijn op het gekozen schalingsmodel.
Applicatieplatform en databases
Daarnaast zijn er fundamentelere keuzes als het gaat om het bouwen van goed schaalbare cloud business-oplossingen. Het begint met de keuze voor het achterliggende applicatieplatform. Microsoft Windows Azure beschikt bijvoorbeeld over diverse kenmerken en functies die helpen om de prestaties te verbeteren, zoals bijvoorbeeld caching. Als ontwikkelaar moet je er voor zorgen dat je in het ontwerp gebruikt maakt van de juiste services die op het Azure-platform beschikbaar zijn, voor de beste prestaties. Er moet ook goed rekening gehouden worden met de inherente beperkingen die in elk basisplatform aanwezig zijn. Relationele databases kunnen de schaalbaarheid beperken.
Ook kunnen de prestaties van SQL Server worden beperkt (‘throttling’), afhankelijk van de actuele prestaties van de database, de gebruikte opslagruimte, de processorbelasting en andere variabelen die constant worden gemonitord. Gelukkig zijn er ook andere manieren voor het opslaan van databasegegevens in de cloud. Table storage kan een interessante alternatieve manier zijn voor het opslaan en opvragen van grote hoeveelheden gestructureerde, maar niet relationele data. Bij deze, op NoSQL principes gebaseerde opslagvorm hoeven geen complexe relaties tussen tabellen te worden bijgehouden. En dat komt de prestaties ten goede. Per Azure storage account kan tot 100TB aan informatie in Tables worden opgeslagen.
Een andere afweging bij het uitrollen van cloud-applicaties is de keuze voor Infrastructure-as-a-Service (IaaS) of Platform-as-a-Serice (PaaS). In het geval van IaaS verzorgt de leverancier de benodigde hardware, opslag en virtualisatiemogelijkheden. De afnemer is verantwoordelijk voor de virtuele machine met het besturingssysteem en alle andere zaken die nodig zijn om de applicatie te draaien. IaaS is met name geschikt voor het migreren van bestaande applicaties naar de cloud, of die gebruik maken van services die nog niet beschikbaar zijn als native cloud service, of draaien op een ander besturingssysteem dan Windows (bijvoorbeeld Linux). Het is echter niet zo dat een niet schaalbare applicatie plotseling schaalbaar wordt wanneer deze zonder aanpassingen in een Azure VM naar de cloud wordt gebracht.
Bij PaaS is het niveau van abstractie hoger. Hierbij zorgt de leverancier bovenop het IaaS-model ook het besturingssysteem, de middleware en de benodigde runtime. Dit heeft als voordeel dat je je als afnemer alleen maar bezig hoeft te houden met daadwerkelijke applicatie. De leverancier is bij PaaS bijvoorbeeld ook verantwoordelijk voor het up-to-date houden van het besturingssysteem met de noodzakelijke patches.
In tegenstelling tot andere leveranciers, zoals Amazon, heeft bij Windows Azure lange tijd de nadruk gelegen op PaaS. Maar met het commercieel beschikbaar komen van Windows Azure Virtual Machines in april 2013, biedt Microsoft nu ook een volwaardige IaaS-oplossing.
Doelstellingen bepalen ontwerp
Hoe goed het achterliggende platform echter ook is, de prestaties en de schaalbare efficiency zijn vooral afhankelijk van het ontwerp van de toepassingen van de keuzes die je daarbij maakt. Het begint bij het achterhalen van de diepere doelstellingen van de klant (of dit nu de eigen organisatie is of een externe klant). Hoe wordt de toepassing uiteindelijk ingezet en wat zijn de realistische gebruiksscenario’s? Natuurlijk spelen ook business-eisen en -doelstellingen een belangrijke rol, zoals kosten, de mogelijkheid om het systeem afhankelijk van het succes te kunnen laten groeien (of krimpen) wanneer dat nodig is, het opvangen van piekbelastingen, organisatorische zaken (geen eigen hardware/beheer) et cetera.
Afhankelijk van de doelstellingen kan daarna gekeken worden welke delen – en in welke mate – de applicatie moeten worden geoptimaliseerd om de gestelde doelen te behalen.
In sommige gevallen is het misschien aan te raden om een hybride oplossing te kiezen, waarbij de delen van een applicatie die het meest geschikt zijn voor een cloud-scenario worden gekoppeld met on-premises oplossingen. Je kan ook denken aan een scheiding van de functionaliteit op basis van het gebruiksmodel. Een publiek deel waar miljoenen hits in korte tijd worden verwacht, is bij uitstek een kandidaat om naar de cloud te brengen. De back-end of business-functionaliteit voor het later verwerken van de gedane transacties kan bijvoorbeeld plaatsvinden door on-premises systemen.
Om de benodigde schaalbaarheid in een cloud-applicatie te realiseren, kan bijvoorbeeld gebruikgemaakt worden van caching en queuing. In veel gevallen is er ook aanzienlijke winst te halen door waar mogelijk statische content vooraf te generen en op te slaan in Azure Blob storage. Deze informatie kan dan zonder verder verwerking door gebruikers worden geraadpleegd.
Samenvattend hier de belangrijkste zaken om rekening mee te houden voor het bouwen van schaalbare websites of diensten:
- Schaalbaarheid van cloud-applicaties is geen kwestie van het ‘even bijschakelen’ van capaciteit; bij het ontwikkelen van webtoepassingen moet schaalbaarheid van meet af aan een integraal onderdeel zijn van het ontwerp;
- Zorg ervoor dat de doelstellingen helder zijn: waarom wil je naar de cloud? Welke concrete voordelen wil je behalen? Stel een realistische verwachting op voor wat betreft de piekbelasting en bepaal aan de hand daarvan je prestatie-eisen en gewenste service levels;
- Denk goed na over welke delen van de oplossing naar de cloud moeten. Het is niet nodig om alles in de cloud te zetten; hybride oplossingen kunnen soms betere prestaties opleveren. Een belangrijke voorwaarde daarbij is echter wel dat al het beheer – zowel in de cloud als on-premises – bij voorkeur vanuit managementomgeving gedaan kan worden;
- Maak optimaal gebruik van extra mogelijkheden die een cloud-platform biedt;
- Maak een bewuste keuze tussen Infrastructure-as-a-Service en Platform-as-a-Service. IaaS is de beste keuze wanneer flexibiliteit en keuzevrijheid in het besturingssysteem, applicatie-ontwikkelplatform, et cetera. voorop staan. PaaS is eenvoudiger uit te rollen en te beheren, en vaak beter schaalbaar.
Scale-out is niet altijd te realiseren, omdat je bepaalde hot spots in je applicatie hebt. Bij het ontwerp van nieuwe applicaties kun je daar wel rekening mee houden, door asynchroniteit toe te voegen. Bijvoorbeeld door boekingen via een speciaal proces sequentieel uit te voeren. De transactie biedt je dan via een queue aan.
Je front-end applicatie (b.v. een website of app) moet er dan wel tegen kunnen dat een transactie toch nog afgekeurd kan worden. Dit zal tot een terugdraai transactie leiden.
Bestaande applicaties zijn echter niet vaak volgens deze manier ontworpen en ze ombouwen kan erg kostbaar zijn.
De boodschap dat Cloud dus niet zonder meer de oplossing van schaalbaarheid is op applicatieniveau is dus terecht.
Degelijk artikel, weinig op aan te merken.
Ik ben ook erg voor scale-out, ofwel distribueren van verwerking en dataopslag en zoals Leen en Arie aangeeft, niet altijd heel gemakkelijk te realiseren.
Code is gewoon code. Je gebruikt dezelfde taal en tools voor software ontwikkeling voor de cloud als voor on-premise, maar de manier waarop je het inzet en toepast maakt het verschil of het klaar is voor schaal of niet.
Wat je vaak ziet is dat software die al jaren goed functioneert naar de cloud gebracht wordt, maar daar eigenlijk niet geschikt voor is. Beter begin je al vroeg opnieuw dan dat je iets bestaand probeert om te buigen. Op de lange termijn is ombuigen altijd duurder (hoewel wel begrijpelijk).
Daarnaast is NoSQl of Table storage een listige en lokt vaak maatwerk uit. Maar uiteindelijk is table storage wel weer schaalbaarder dan relationele data.
Een groot verschil met schaalbaarheid in Windows Azure versus on-premise is in ieder geval dat er in Windows Azure al zeer veel faciliteiten zijn gemaakt om schaalbaarheid te realiseren, de website zelf (WindowsAzure.com) bevat al zeer veel materiaal om je daar bij te helpen.
Goed artikel.
Schaalbaarheid is altijd lastig te kwantificeren en een afweging van de kosten tegen het daadwerkelijk gebruik. Hoeveel gebruikers tegelijkertijd belasten welke delen van de keten en waar zitten de hot spots, dus die delen die moeilijk te schalen zijn zoals het netwerk naar de cloud. Belangrijk is dat je vooraf bewuste keuzes maakt die zijn onderbouwd, zodat je in de toekomst makkelijker kunt schalen op de plaatsen waar het nodig is.
Met de huidige virtualisatie technieken is scale up ook goed realiseerbaar doordat de workload kan worden verdeeld binnen een fysieke server en je capaciteit on the fly kunt vrijmaken. Servers zijn meestal niet de bottleneck, de storage (en het storage netwerk), het netwerk en de applicaties zijn de kritische factoren.
Het klopt dat schaalbaarheid mee moet worden genomen in het ontwerp van het artikel. Toch zal dat door PaaS oplossingen minder belangrijk worden. Een oplossing die je niet noemt is OpenStack, een open source Platform-as-a-Service oplossing die bedoeld is om cloud applicaties (dus schaalbaar) voor te ontwikkelen.
Met dit soort oplossingen wordt het mogelijk om onderliggende hardware of zelfs complete netwerken aan te passen zonder dat de applicatie herschreven hoeft te worden. Volgens mij een ontwikkeling met toekomst. Maar misschien inderdaad geen oplossing die voor elke applicatie geschikt is.
In de praktijk kom ik vaak systemen met performance problemen die niet worden veroorzaakt door een tekort aan capaciteit van het geheel. Veel van de beschikbare capaciteit niet wordt gebruikt doordat processen staan te wachten om toegang te krijgen tot langzame, of in het ergste geval niet beschikbare, resources zoals databases of services. Het toevoegen van nog meer resources in wat voor scenario dan ook is dan ook niet effectief in dit soort scenario’s zonder te kijken waar de echte bottleneck in het systeem zit.
Juist nu steeds software ontwikkelaars gebruik gaan maken van asynchrone technieken om de capaciteit van bijvoorbeeld een webserver efficiënter te gebruiken wordt dit steeds actueler. In plaats van te wachten op het resultaat van een lang durende transactie wordt de capaciteit ondertussen benut voor het afhandelen van een volgende aanvraag. Doordat de webserver beter wordt benut en met dezelfde capaciteit meer aanvragen kan verwerken verdwijnt er een ‘comfortabele’ buffer tussen de webserver en de backend waardoor die nog harder zal worden geraakt door piekbelastingen.
Voor de totale schaalbaarheid van een oplossing is het noodzakelijk de dat de efficiency en capaciteit van de afzonderlijke onderdelen waaruit deze is opgebouwd op een voor dat onderdeel optimale manier kan worden uitgebreid. In plaats van het maar blijven bijschakelen van extra servers kan het veel doeltreffender zijn om tijdens het ontwerp, of bij een migratie naar een cloud omgeving, gebruik te maken van de services die beschikbaar zijn op het platform. Denk hierbij aan caching, queues en meer optimale manieren van data opslag zoals bijvoorbeeld de NoSQL data opslag in Azure Tables.