Checklist deel 3: Schaal je resources op Azure - De basis

Wanneer je bezig bent met het ontwikkelen van een nieuwe softwareoplossing dan denk je waarschijnlijk niet meteen aan schaalbaarheid. Je wilt eerst weten hoe de markt reageert, of er groeimogelijkheden voor je software zijn, of je bent het misschien vergeten. En dit is oké. Maar uiteindelijk zal de performance en het resource gebruik het capaciteitslimiet bereiken. Dus wat zijn je opties? Met Microsoft Azure heb je een groot platform beschikbaar voor jou, met verschillende schaalmogelijkheden.

Let op: vanuit een technisch perspectief komt er veel meer bij kijken, echter is kennis van de verschillende concepten en mogelijke implicaties rand voorwaardelijk. Want hoewel het schalen van je oplossing meestal een technische exercitie is, heb je nog wel een strategie en een plan nodig, net zoals je deze nodig hebt voor het laten groeien van je bedrijf.

Maar waar begin je? Heb je wel alleen meer processorkracht nodig? Wil je dynamisch schalen en hoe snel groei je op dit moment? Is deze groei lokaal, regionaal of wereldwijd? Dit zijn veel vragen om te beantwoorden, dus laten we beginnen bij de basisprincipes en de opties.

De basisprincipes van schalen
Laten we eerst kijken naar horizontaal en verticaal schalen. Denk hierbij aan het volgende scenario: je start een transportbedrijf waarbij je mensen naar het vliegveld vervoert. Na verloop van tijd merk je dat de auto het moeilijk heeft om het gewicht van de bagage te dragen en moet je klanten weigeren omdat de auto vol is. Je vraagt ze te wachten tot de volgende ronde en voordat je het weet moeten je klanten wachten op de parkeerplaats en wordt de rij langer en langer.

In feite hebben we het hier over een vraag en aanbod scenario waarbij jouw auto de vraag simpelweg niet aan kan. Dus we moeten gaan kijken hoe we dit gaan oplossen.

Verticaal schalen
Als we het hebben over verticaal schalen dan praten we over scenario’s waarbij je ‘’opschaalt’’ en ‘’afschaalt’’. Als je dit vertaalt naar het eerdergenoemde voorbeeld dan is in feite wat je gaat doen: het groter maken van de auto. Je krijgt een grotere auto met wellicht een aanhanger erbij. Het nadeel hiervan is dat je moet wachten totdat de auto klaar is voor gebruik. Dit moet je van tevoren plannen en regelen, en je moet je auto buiten werktijd omruilen of je klanten moeten even wachten. Maar als de grotere auto eenmaal geregeld is, dan ben je weer klaar om te gaan!

Na verloop van tijd groeit het bedrijf meer en meer en dit zorgt ervoor dat het probleem (de maximale capaciteit van de auto) weer wordt bereikt. Maar wat moet je nu doen? Een grotere auto regelen, een busje of zelfs een groter vervoersmiddel (zoals een touringcar)?

Het regelen van nieuwe vervoersmiddelen kost tijd en er is natuurlijk een limiet tot hoe ver je kan groeien. Want stel je regelt een grotere bus en de vraag wordt weer groter? Of wat als de piek zich bevindt tussen 10:00 en 14:00? Blijf je dan de duurdere bus de hele dag door inzetten? Als je gestaag groeit en je kan de groei een beetje voorspellen dan is dit natuurlijk geen enkel probleem. Maar dit kan op lange termijn in zekere zin een probleem worden.

Kortom, wat je hier doet is het toevoegen van meer capaciteit en dit is ook precies wat je doet als je verticaal je resources gaat schalen. Je voegt meer CPU en geheugen toe aan je systeem om aan de vraag te kunnen voldoen. Het upgraden hiervan zorgt over het algemeen voor downtime (bij Azure is dit slechts enkele seconden/minuten, afhankelijk van het type bron). Dit betekent dat je vooruit moet plannen en dat je niet wilt opschalen gedurende piekuren. 

Verticaal schalen op Azure kan worden gedaan met vrijwel elke resource. Maar net zoals bij het voorbeeld hierboven genoemd is er een limiet. De vuistregel is: opschalen verhoogt de beschikbaarheid niet, je bent nog steeds bezig met één auto.

Aan de andere kant is er over het algemeen nooit een probleem / implicatie bij het opschalen en is dit zeer effectief. Je voegt in feite meer vermogen toe en zo creëer je voor je oplossing meer ruimte om te ademen.

Als je nog niet nagedacht hebt over schalen bij het bouwen van je software dan is verticaal schalen het beste om te beginnen. Wat belangrijk is om te doen is het bepalen van je schaalstrategie voordat je je limiet bereikt. Het mooie aan Azure is dat je makkelijk kan opschalen, meer power kan toevoegen en zodra je het niet meer nodig bent dan kun je weer afschalen. De kosten schalen mee want je betaalt bij Azure alleen voor wat je gebruikt.

De beste timing om verticaal te schalen is doorgaans buiten reguliere gebruikstijde om de impact voor je klanten te minimaliseren.

Lang verhaal kort: Het is een goede manier om te beginnen!

App Service - Vertical Scaling

Horizontaal schalen
Het alternatief voor verticaal schalen is horizontaal schalen.
Met horizontaal schalen kijk je niet naar het upgraden van je huidige auto. Je voegt simpelweg meer auto’s en chauffeurs toe. Hier komen wel andere logistieke uitdagingen bij kijken, maar je hoeft je nu geen zorgen meer te maken over de beschikbaarheid van de auto’s tijdens piekuren. Je kunt ervoor kiezen om tijdens de piekuren 5 auto’s in te zetten en tijdens de ‘’daluren’’ slechts 2. Voeg hier slimme tooling voor capaciteitsplanning aan toe en je kunt de bestuurders automatisch een bericht sturen wanneer de vraag afneemt en je ze de rest van de dag niet meer nodig hebt. Dit klinkt behoorlijk flexibel, niet? Dit is wat we doen bij horizontaal schalen. Je voegt niet meer power (of upgrades) toe aan 1 specifieke auto, maar je voegt gewoon meer auto’s toe aan de pool.

Nu is de uitdaging om de belasting/vraag over de auto’s te verdelen. Verdeel je de passagiers evenredig over de auto’s? En zijn alle auto’s geschikt voor elk type passagier?

Als je dit naar Azure vertaalt kan dit een beetje verwarrend zijn. Horizontaal schalen configureren werkt bij verschillende platform op Azure net iets anders. Als je gebruik maakt van Infrastructure-as-a-Service (IaaS) dan heb je meerdere virtuele machines nodig (of instanties als je gebruik maakt van VM Scale sets), moet je een load balancer configureren en is Infrastructure as Code in principe een vereiste.

Als je gebruik maakt van Platform as a Service (PaaS) zoals Web Apps, dan is horizontaal schalen mogelijk door simpelweg met een slide-bar het aantal instances te verhogen. Je kan automatisch schalen op basis van statistieken zoals CPU, geheugen en IOPS of een customized configuratie indien je dit nodig hebt. En als je voor de serverless propositie gaat dan hoef je je hier helemaal geen zorgen over te maken, dan doet Azure dit allemaal voor je.

Zit er een addertje onder het gras? Ja, als je echt dynamisch wilt zijn dan wil je er eigenlijk voor zorgen dat je applicatie stateless is. Heb je een vorm van caching nodig, dan kun je kijken in oplossingen zoals Azure Redis Cache of Azure Service Bus.

Horizontaal schalen werkt ook goed bij microservices architecturen en gedistribueerde systemen. Maar als dit is waar je je mee bezig houdt dan is het zeer waarschijnlijk dat je al gebruik maakt van horizontaal schalen.

Maar de kans is aanwezig dat je hier nog niet aan gedacht hebt toen je begon met het bouwen van je oplossing en afhankelijk van je applicatie kan het best een project zijn, de transformatie van stateful naar stateless.

App Service – Horizontal scaling

‘’Geweldig, bedankt voor de informatie. Maar moet ik nu verticaal of horizontaal schalen?’’

Wanneer je jouw oplossing migreert naar Microsoft Azure dan kan je kiezen uit beide opties. Als je een bestaande oplossing hebt en de stap van stateful naar stateless te groot is voor nu dan is verticaal schalen the way to go. Maar zoals eerder gezegd; je moet je onderhoud goed plannen. De volgende stap zou zijn om je oplossing geleidelijk stateless te maken - voordat je het schaallimiet van verticaal schalen bereikt. 

Als je nu Infrastructure as a Service (IaaS) gebruikt dan kan het even duren voordat je de limieten van verticaal schalen bereikt. Maar vergeet niet dat high performance virtuele machines over het algemeen niet heel goedkoop zijn. Ook wil je waarschijnlijk je development kosten en impact van een transformatie naar een stateless oplossing vergelijken met de kosten van een duurdere virtuele machine. Kijk hiervoor ook goed naar de ontwikkeltijd / doorlooptijd zodat je een goede vergelijking kunt maken. Hetzelfde geldt voor platform as a service, maar je zult hier waarschijnlijk iets eerder de limieten bereiken.

Een lang verhaal kort: Verticaal schalen is een quick win bij het overstappen naar Azure, maar als je van plan bent op korte termijn snel te groeien dan kan horizontaal schalen (of een combinatie van beide) het ideale concept zijn, omdat dit een hoger niveau van beschikbaarheid geeft en meer flexibiliteit biedt (financieel).

Wereldwijd schalen
Een van de dingen waar Microsoft Azure in uitblinkt is de wereldwijde beschikbaarheid. Je kan je oplossing letterlijk over de hele wereld inzetten, met slechts één druk op de knop. Maar wat betekent dit voor je software architectuur en voor je technische infrastructuur? Wat je wilt bereiken wanneer je je oplossing wereldwijd schaalt is lokale aanwezigheid in een specifieke regio. De technology stack die je gebruikt heeft invloed op de wereldwijde schaalbaarheid (gebruik je IaaS, PaaS of serverless?) Wat is je business case? Wil je een kopie van je architectuur opnieuw implementeren in een specifieke regio en zo de kosten verdubbelen? (let op: de kosten per regio kunnen verschillen) en ga je dit doen voor één klant? En hoe zit het met de wet -en regelgeving?  

Overwegingen voor wereldwijd schalen
Als je wereldwijd wilt schalen dan zijn er drie onderwerpen die van belang zijn voor je strategie:

• Financiën
• Latency
• Compliance, lokale wet- en regelgeving

Financiën
Bij het kopiëren van je omgeving naar een andere regio zullen je kosten minimaal verdubbelen. Als je momenteel een oplossing levert aan honderden klanten en je schaalt naar een andere regio voor speciaal 1 klant dan is dit waarschijnlijk niet ideaal. En laten we eerlijk zijn: dit is vaak hoe het eruit ziet in het begin (hoe zeker ben je dat je meer klanten gaat onboarden in die specifieke regio de komende periode?).

Dit is waar de strategie voor verticaal en horizontaal schalen om de hoek komt kijken. Als je een van de twee zou willen implementeren, dan is je doel om terug schalen naar het minimale dat vereist is voor slechts een aantal klanten, terwijl de beschikbaarheid hetzelfde blijft. Dit is waarom je moet begrijpen waarom en wanneer je (moet) schalen. Je wilt in control zijn van je capaciteits-eisen vs. het gebruik.

Latency
Verreweg de meest belangrijke asset bij het wereldwijd schalen van je oplossing is data. Je wilt de data opslaan in de buurt van je klanten. Laten we eerst kijken naar databases. Wanneer we kijken naar Microsoft Azure dan zijn er een paar opties. Als je IaaS gebruikt en een MSSQL database host op een virtuele machine dan ben je hoogstwaarschijnlijk beperkt tot het uitrollen van de vm in een andere regio met de specifieke data van de klant voor die regio, gehost op die machine.

Als je wereldwijd wilt schalen dan is PaaS de go-to technologie die Microsoft aanbiedt. Als het gaat om database services dan zijn er twee oplossingen die wereldwijd gebruikt worden:

Platform as a Service (PaaS) met Azure SQL
Azure SQL ondersteunt database sharding. Lang verhaal kort: dit helpt je om de data op te delen in kleinere stukjes en zo kun je deze ze opslaan in verschillende regio’s wat resulteert in betere performance. Houd er wel rekening mee dat dit je architectuur complexer maakt.

Gedistribueerde dataservices
Gedistribueerde databases zijn gebouwd voor horizontale schaalbaarheid en wereldwijde distributie. Je kan je gegevens naar een specifieke locatie schrijven en van een specifieke locatie lezen terwijl je gebruik maakt van een enkel frontend “(laten we zeggen een Azure Web APP). Dit lijkt op database sharding maar gedistribueerde dataservices zijn veel meer dan dat op het gebied van replicatie, schaalbaarheid en partitioning. Azure biedt een van deze services aan in de vorm van CosmosDB en is onderdeel van de serverless propositie. Let op dat dit waarschijnlijk een andere database model / schema vereist dan dat je nu gebruikt. Maar als je wereldwijd wilt schalen dan is CosmosDB een van de services die je zou moeten overwegen.

Naast databases is er ook nog de content waar we rekening mee moeten houden. Ten eerste wil je de content dicht bij je klanten opslaan en aanbieden, zonder dat je het moet kopiëren en plakken over de hele wereld. Lang verhaal kort: je hebt een content delivery Netwerk nodig. Microsoft biedt dit in de vorm van Azure CDN. Azure CDN biedt een integratie met de meeste PaaS services.

En uiteraard wil je de gebruikers maar één endpoint (URL) aanbieden aanbieden, ongeacht vanuit welke regio zij willen inloggen. Afhankelijk van jouw use case kan Azure Traffic Manager de uitkomst bieden. Gebaseerd op DNS zal Traffic Manager jouw gebruikers leiden naar het backend welke het dichtste bij staat (de dichtstbijzijnde Azure Regio waar jou oplossing is uitgerold).

Compliance en wet- en regelgeving
Dit is het onderwerp waarover je alle antwoorden wil hebben wanneer je met je klanten praat. Afhankelijk van waar jouw klanten zich bevinden zijn er wellicht verschillende vereisten/regels voor het opslaan van data. Als vuistregel wil je de gegevens opslaan daar waar je klanten zich bevinden, althans tenminste in hetzelfde land/regio waar dezelfde wetten en regels gelden. Dit zou je waarschijnlijk sowieso al doen om latency te voorkomen maar dit wederom een reden om de data dicht bij de klant op te slaan.

Wanneer we het hebben over compliance biedt Microsoft het Trust Center waar je alle compliance aanbiedingen kan zien welke Microsoft biedt. Bovendien heeft Microsoft uitgebreide documentatie over hoe Azure is opgebouwd vanuit een security perspectief. Bijvoorbeeld isolatie. Dit is vaak een onderwerp waar veel vragen over worden gesteld tijdens onboarding-sessies. Het is niet zo dat je altijd invloed hebt op de Azure Architectuur maar het is van belang dat je de design keuzes van Microsoft begrijpt en kunt uitleggen aan je klanten.

Wat belangrijk is, is dat je kijkt naar hoe je jouw gegevens distribueert en dat je alle technologische vereisten kan implementeren welke gelden voor dat land. En in de meeste gevallen als je kiest voor de opties zoals hiervoor zijn beschreven, voldoe je grotendeels. In zeldzame gevallen kunnen er andere vereisten zijn (zoals overheidsklanten). In deze gevallen heeft Microsoft geïsoleerde regio’s ontworpen zoals Azure Government.

Samenvattend
Er zijn verschillende manieren waarop je kunt schalen en elke strategie heeft verschillende implicaties voor je oplossing. Wat belangrijk is om te weten is dat er altijd een ‘’quick win’’ is en of je nu wel of niet van tevoren hebt nagedacht over de mogelijkheden van verticaal, horizontaal en globaal schalen, het verplaatsten van je oplossing naar Azure zal zeker voordelen hebben. Alle technologieën zijn er om te gebruiken en om succesvol je business te laten groeien maar het is aan jou om te bepalen wat jouw ‘’quick wins’’ zijn en wat de doelstelling is op zowel korte als lange termijn.

In onze volgende checklist gaan we in op het onderwerp: beschikbaarheidseisen voor jouw applicatie op Azure.