Wat zal een Windows Azure specialist zeggen als je vraagt wat zo mooi is aan Windows Azure? Heel vaak zul je dan horen, dat je naar behoefte kunt schalen. Daarbij komen dan de plaatjes van de zogenaamde sweet spots naar voren:
De sweet spots zijn:
- On and Off scenario
Voor processen of applicaties die een periode van stevig gebruik kennen, maar ook een periode helemaal niet. Voor de periodes dat de applicatie niet gebruikt wordt, is het handig om deze dan ook echt helemaal uit te zetten. Bijvoorbeeld het berekenen en bijwerken van verlofdagen, of het analyseren van data na een periodieke aanlevering van data.
- Predictable Bursting
Voor processen of applicaties die altijd wel gebruikt worden, maar gedeeltes van een tijdsperiode intensiever. Bijvoorbeeld het invoeren van uren, sommige collega’s doen dat iedere dag anderen altijd aan het einde van maand, waardoor er dan een piek ontstaat. Deze piek is planbaar en voorspelbaar.
- Unpredictable Bursting
Voor processen of applicaties die ook een piek kennen, maar waarbij deze niet duidelijk voorspelbaar is. Bijvoorbeeld het aanslaan van een markering acties bij een online shop. Een typische tegenhanger van de vorige, waarbij er snel capaciteit bijgeschakeld worden en wanneer dit niet meer nodig is teruggeschakeld kan worden.
- Growing Fast
Een applicatie of idee, wat klein begint maar uitgroeit tot een knaller. Bijvoorbeeld de nieuwe Facebook of Hyves.
Maar dit is nog steeds niet iets specifiek voor Windows Azure. Tenslotte is Mark Zuckerberg zijn Facebook ooit begonnen vanuit zijn studentenkamer op Harvard. Hij had nog niet de beschikking over Windows Azure, maar moest wel schalen na mate er meerdere gebruikers van Facebook kwamen. Nu was dat op dat moment een redelijke predictable bursting scenario, maar vergde toch een investering voor extra hardware. Zou je nu weer zo iets doen, dan zullen de initiële investeringen hoger zijn. Maar welke bank zal je daarbij helpen? Facebook is ook groter geworden dan de critici ooit dachten.
Voor schaling moet kosten en baten wel in evenwicht blijven
En dan is het wel handig, dat je zonder investeringen vooraf, toch capaciteit kunt bijschakelen. Ten slotte heb je capaciteit nodig omdat het gebruik van de applicatie groeit waarbij er in een business case rekening mee wordt gehouden dat de inkomsten dan ook groeien. Maar wat nou als de groei ineens stopt of erger ineens afneemt? Als je dan investeringen hebt gedaan, dan zit je met overcapaciteit die naar verhouding er duur is. Wat dan? Dan zou het prettig zijn als je die over capaciteit kunt stoppen en je er niet meer voor hoeft te betalen.
Amazon kende ook altijd een Predictable Bursting. Zo rond de kerstdagen stegen het aantal bezoekers aan hun webshop altijd structureel. Om deze enorme piek op te kunnen vangen hadden ze voldoende capaciteit staan. Maar deze capaciteit was maar een deel van het jaar kosten efficiënt. Zij bedachten toen dat ze de overcapaciteit wel konden verhuren als zij hem niet nodig hadden. Helaas liepen ze daarbij de volgende kerstdagen weer tegen een probleem op.
Kortom schaalbaarheid is bedoeld om de schommelingen in vraag en aanbod van capaciteit goed te verdelen.
Nog steeds is dit niet echt Windows Azure specifiek. Ten slotte geldt dit ook voor de vele applicaties die we on-premise in onze eigen datacenters draaien. Maar door de eenvoudig en de betrekkelijk lage en wazige kosten worden we niet meer gedwongen om afwegingen op basis van kosten te maken.
Nu kennen we twee soorten van schaling. Daarom eerst maar even de terminologie:
Op het Windows Azure platform kennen we 5 verschillende Virtual Machines die verschillen in capaciteit. Dat is ’scale up’. Deze manier van schalen wordt veel gebruikt bij on-premise applicaties. We kopen grotere en zwaardere hardware. Op Windows Azure kies je vooraf welke grote van de VM je kiest. Deze keuze bepalen ook de kosten, cpu, memory en local storage.
Als je op Windows Azure in de ServiceConfiguration.csdfg het aantal instanties verhoogd van de default 1 naar meer, dan spreken we van ‘scale out’. Bij een on-premise situatie zou je dan een tweede gelijksoortige machine bijplaatsen en het verkeer tussen beide via een Loadbalancer laten regelen. Dit is wat er op Windows Azure ook gebeurt, waarbij het platform dit geheel voor je verzorgt
Deze ‘scale out’ mogelijkheid is op het Windows Azure platform bijna onbeperkt, maar er ligt nu een grens op 5 rollen per hosted service. Deze grens is niet hard en via de Support desk kan deze opgehoogd worden.
Maar letop ‘scale up’ heeft niets te maken met fail over. Voor fail over heb je een ‘scale out‘ nodig.
Scale up != Fail Over, maar Fail over == scale out
Zo bestaat een fail over cluster in een on-premise situatie ook altijd uit meer dan 1 machine. Om die reden moet je op Windows Azure ook altijd twee instanties van een service hebben draaien om fail over te kunnen garanderen in het geval van een OS update of hardware failure.
Uiteraard is er ook nog een tussen weg tussen ‘scale up’ en ‘scale out’. Meerdere processen draaien binnen 1 goed gedimensioneerde Virtual Machine (scale out) en dan meerdere van deze Virtual Machines naast elkaar.
Of in het totaal plaatje:
Dit alles valt of staat wel of het proces of de applicatie ook daadwerkelijk schaalbaar is. Een web applicatie of website zou altijd al stateless moeten zijn, ten slotte hoeft een request niet telkens bij dezelfde webserver terecht te komen. Een applicatie moet geschreven worden vanuit het oogpunt dat hij niet alleen is, waarbij hij mag ook niet weten wie er nog meer zijn.
Dit geldt ook voor WorkerRollen of processen. Om ‘scale out’ met WorkerRollen goed te kunnen implementeren gebruik je queues om het werk te verdelen. Iedere Worker pakt een of meer Workitems uit het bakje en gaat deze verwerken. Als hij klaar is, pakt hij de volgende set etc.
Let op: deze aanpak brengt wel met zich mee dat je rekening moet houden dat een worker kan crashen. In dat geval moet het werk dat hij heeft opgepakt natuurlijk niet verloren gaan. Dit is analoog aan Workitems in TFS. Als een developer een aantal Workitems op zijn naam heeft en hij wordt ziek, dan moeten de Workitems door een andere overgenomen kunnen worden. Stel dat de Worker crasht als hij geld op je rekening moet bijschrijven dan moet de transactie nog wel blijven bestaan. Zou je dit niet doen, dan wordt het heel vervelend als het proces je bankrekening bijwerkt.
Kortom omgaan met schaalbaarheid is een architectuur beslissing. Als je voor een bepaalde structuur gekozen hebt, dan kan het moeilijk zijn om te veranderen. Natuurlijk kun je ook je applicatie automatisch laten schalen. Dit zal je dan wel zelf moeten inbouwen, maar het is heel goed mogelijk. Het lastige hierbij is niet zozeer het opschalen zelf, maar het terug brengen van het aantal instanties. Op welke signalen of parameters reageer je bijvoorbeeld als je terug kunt naar minder instanties van je service.
De eenvoud en de dynamiek waarmee je in Windows Azure een ‘scale out’ kunt doen, is een van de grote voordelen van het platform. Vooral omdat de wijze geen investeringen vooraf verlangt en je toch kunt reageren op de vraag. Daarnaast hoef je niet een systeembeheerder lastig te vallen, maar kun je als applicatie beheerder dat zelf.