Applicatiehosting in Azure met Azure WebApps

Een App Service wordt ondergebracht in een App Service Plan. Deze kunnen geconfigureerd worden in verschillende tiers. Basic, Standard en Premium (V2, 3 of 4) zijn gangbaar voor moderne productieomgevingen. Hierbij is Basic de goedkoopste optie en Premium de duurste. De onderliggende hardware van de Basic tiers is dan ook van mindere kwaliteit dan die van de Standard tiers. De Premium tiers draaien weer op betere hardware. Onderstaand een indicatie van de prijzen van de verschillende tiers

Klik hier om de prijzen van de verschillende tiers te zien.
Tip: filter je OS op Windows, Region op West Europe en Currency op Euro.)

Ook biedt Basic minder features dan de Standard en Premium tier App Service Plans.

Microsoft biedt een SLA van 99,95% voor alle benoemde tiers: dit betekent dat de applicatie ongeveer 22 minuten per maand offline mag zijn. Geo-redundancy is niet op App Service Plan niveau in te stellen. Wel kan bij Premium tiers Zone-redundancy worden geconfigureerd om te zorgen dat de applicatie blijft werken als er onderhoud of een storing optreedt in de zone waar de App Service draait. Als de hele regio (bijvoorbeeld West-Europa) eruit ligt, is je applicatie echter offline.

Ook dit valt natuurlijk te voorkomen: Door je App Service Plan in verschillende regio’s te hosten en een globale load balancer oplossing (bijvoorbeeld Azure Frontdoor) voor de App Service te plaatsen, kan ook worden omgegaan met regio brede storingen.

Het is vanzelfsprekend dat bij een moderne applicatie gebruik wordt gemaakt van release pipelines. Handmatig vanuit je IDE opleveren is leuk voor hobbyprojecten, maar onacceptabel in een professionele omgeving. Door het releaseproces vast te leggen en gestandaardiseerd te automatiseren via de release pipeline (wij gebruiken vooral Azure DevOps Pipelines), kun je ervoor zorgen dat er geen onverwachte situaties ontstaan tijdens oplevering.

Belangrijke onderdelen van de moderne release pipelines zijn allerlei kwaliteitscontroles en geautomatiseerde tests om zeker te zijn dat wat je oplevert ook zal werken als het op zijn plek staat.

Vervolgens kan de pipeline de infrastructuur opbouwen in Azure met Infrastructure-as-Code. Wij gebruiken vooral Bicep. Hierdoor kan de infrastructuur bij creatie en wijziging eenvoudig gecontroleerd worden door collega’s, en is het ook eenvoudig dezelfde infrastructuur eventueel ergens anders neer te zetten. Een basisopzet van een App Service Plan met App Service in Bicep ziet er als volgt uit:

Pas na de infrastructuur-deploy wordt de applicatie op de App Service neergezet.

Het opleveren van een applicatie op een App Service vereist dat de oude versie van de applicatie wordt gestopt. Dat betekent dat de applicatie even down zal gaan. Om dit te voorkomen faciliteert Microsoft in het gebruik van deployment slots. Je deployt de applicatie eerst op een staging slot en geeft de applicatie de tijd om op te starten. Vervolgens voer je een slot-swap uit: de interne load balancer routeert het nieuwe verkeer naar de slot waar je de applicatie hebt opgeleverd, totdat al het lopende verkeer op de oude slot is afgehandeld. Vervolgens wordt de oude staging slot de nieuwe productie slot. Deployment slots zijn als volgt in te richten in je Bicep-template:

Idealiter wordt ergens tussen oplevering van de applicatie op de staging slot ook een geautomatiseerde test tegen de slot uitgevoerd, om te valideren dat alles operationeel is. Zo kunnen verdere issues met de nieuwe versie van de applicatie worden afgevangen, vóórdat ze een verstoring kunnen veroorzaken. Deployment slots zijn niet beschikbaar op de Basic App Service Plans.

Zoals eerder getoond zijn er verschillende niveaus qua hardware te configureren. Belangrijk bij een eerste oplevering is om goed te kijken of er voldoende resources beschikbaar zijn voor de applicatie en de hoeveelheid gebruikers. Het CPU- en geheugengebruik dienen dus de eerste periode goed in de gaten te worden gehouden. Het kan verstandig zijn bij een eerste release met meer cores en geheugen te beginnen dan je denkt nodig te hebben; terugschalen is altijd een optie, bij opschalen ben je snel te laat.

Om te zorgen dat het systeem met de verwachte load om kan gaan, zijn er twee schalingsvectoren: upscaling (verticaal schalen) en outscaling (horizontaal schalen). Bij Upscaling verhoog je de beschikbare resources op de server: bijvoorbeeld van S1 naar S2. Zo heeft iedere applicatie op het plan dus méér cores en RAM beschikbaar. Upscaling wordt over het algemeen gebruikt om de gemiddelde belasting van het systeem en kleine piekbelastingen te kunnen verwerken. Nadelen van upscaling zijn dat het tijd kost, dat de applicatie een aantal seconden offline kan gaan en dat het niet eenvoudig geautomatiseerd kan worden.

Voor piekbelastingen kan outscaling (horizontaal schalen) worden toegepast. Wanneer een App Service Plan horizontaal geschaald wordt, worden extra machines ingericht met alle applicaties die op het App Service Plan staan. Vervolgens wordt de interne load balancer van het App Service Plan aangepast om verkeer naar de verschillende instanties te routeren. Dit proces kan binnen een aantal seconden zijn afgerond. Zo is het systeem weerbaar voor plotselinge pieken. Het is mogelijk om dit proces geautomatiseerd te laten verlopen, dit heet autoscaling.

Autoscaling is een proces waarbij in Azure kan worden ingericht dat het horizontaal schalen van een resource, in dit geval het App Service Plan, automatisch wordt uitgevoerd. Er kan een set regels worden ingeregeld waaraan voldaan moet worden om méér of minder servers te laten draaien. Een basisopzet van automatische opschaling zou er bijvoorbeeld zo uit kunnen zien:

Met deze opzet wordt automatisch naar 10 instances geschaald als de druk op de CPU in een tijdspanne van 5 minuten hoger dan 95% is, waarna geleidelijk met 1 instance per keer afgeschaald wordt als deze gedurende 5 minuten lager dan 80% is. Door snel op te schalen en langzaam terug te schalen worden dan wel meer kosten gemaakt (elke instance kost het tarief van het App Service Plan), maar kun je zekerder zijn van beschikbaarheid van de applicatie. Autoscaling is niet beschikbaar op de Basic tier App Service Plans.

Azure is een degelijk platform, maar er kan altijd iets fout gaan op hardware- of softwareniveau. Windows App Service Plans zijn platgeslagen niet meer dan een IIS-server met een Azure-laag eroverheen. Binnen IIS kan iets als bestandscorruptie optreden. Op zo’n moment is de applicatie niet meer bereikbaar. Om dit te voorkomen kan op App Services een health check endpoint worden geconfigureerd:

Dit path laat je wijzen naar een API-endpoint waar je valideert dat de applicatie werkt. Dit kan zo simpel zijn als een 200-response terugsturen. Azure bevraagt het endpoint van elke instance 1 keer per minuut. Als de instance meer dan 10 minuten geen positieve reactie geeft, wordt vanuit de load balancer al het verkeer naar de instance gestopt. Vervolgens wordt het endpoint instance op de achtergrond nog 50 minuten bevraagd. Als de instance niet positief reageert in die tijd, wordt de gehele instance opnieuw opgebouwd en geherintroduceerd in de load balancer. Voor alle eerdergenoemde App Service Plan tiers behalve de Basic tier geldt dat, ook als er maar 1 instance draait, deze opnieuw wordt opgebouwd. Dit gebeurt maximaal 3 keer per dag per app service, en zou voldoende moeten zijn om de beschikbaarheid van de applicatie verder te garanderen

De rode draad bij het hosten van applicaties in Azure WebApps is dat techniek en inrichting minstens zo belangrijk zijn als de code van de applicatie zelf. De keuze voor onder anderen App Service Plan tier, multiregionaal ontwerp, release pipelines, autoscaling en health checks bepaalt uiteindelijk of je applicatie onder load beschikbaar blijft en voorspelbaar te beheren is.

Wie deze aspecten vanaf het begin meeneemt in het ontwerp, legt de basis voor een platform waarop nieuwe functionaliteit veilig, herhaalbaar en zonder verstoringen kan worden uitgerold – precies waar moderne, cloud‑native applicaties om vragen.