Centric connect.engage.succeed

Static website hosting voor Azure storage: hot or not?

Geschreven door Bas Peeters - 09 oktober 2018

Bas Peeters
Een aantal weken geleden ging Static website hosting voor Azure Storage in public preview. Hiermee krijg je de mogelijkheid om files in Azure Storage te zetten en deze rechtstreeks vanuit je browser te benaderen. Leuke feature, maar wanneer gebruik je het?

Veel moderne webapplicaties bestaan uit een frontend- en een aantal (kleine) backend-services. De frontend is vaak een op zichzelf staande applicatie, gebaseerd op JavaScript frameworks, zoals Angular of React. Bij het hosten van dit soort applicaties in Azure gebruikte ik tot nu toe een Web App. Maar als je er goed over nadenkt, is dat eigenlijk een beetje overkill. Natuurlijk, App Services zijn mooie PaaS-componenten en geven je veel keuze uit verschillende tiers. Bovendien bieden ze flexibele schaalbaarheid en hoef je weinig aan onderhoud te doen. Maar voor het hosten van een Angular-app heb je niet veel rekencapaciteit of geheugen nodig. Het zijn tenslotte clientside-applicaties, waarbij de server alleen dient voor het downloaden van de files naar de client; de applicaties doen geen andere bewerkingen. En dit is precies waarom Static website hosting voor Azure Storage een goed alternatief kan zijn.

Features

De vraag is wel of alle key features van Web Apps ook aanwezig zijn in Static website hosting voor Azure Storage. Laten we eens kijken naar de volgende (voor mij) belangrijke features: 

  • custom domains en SSL-support
  • auto scaling
  • staging slots
  • deployment opties

Custom domains en SSL-support

Net als Web Apps heeft Azure Storage standaard custom domain en SSL-support. Maar voor frontend-applicaties wil je vaak een combinatie van deze twee. Je wilt je applicatie achter een nette en passende URL zetten en SSL aan hebben staan om de moderne browsers tevreden te houden.

Wat blijkt? Het is niet mogelijk om zelf op de Azure Storage service een custom domain samen met SSL in te stellen. Hiervoor moet je een CDN gebruiken. Het resultaat is hetzelfde, maar je moet wel wat meer investeren op het gebied van je infrastructuur.

Auto scaling

Scaling bij Azure Storage is automatisch geregeld. Dus geen auto-scale rules voor op- en afschalen; de service schaalt automatisch, afhankelijk van het gebruik. Een pluspunt ten opzichte van Web Apps, waar je wel nog zaken in moet stellen.

Staging slots

Het concept staging slots bestaat niet in Azure Storage. Dit is natuurlijk niet vreemd, want Azure Storage was tot nu toe vooral bedoeld als opslagmedium en niet zozeer als hosting service.

Ik gebruik staging slots in Web Apps vooral om te testen of een nieuwe versie van mijn applicatie nog naar behoren werkt voordat deze live gaat. Na het succesvol afronden van de test, kan ik de slots wisselen en draait mijn applicatie zonder downtime op de nieuwe versie. Wat er op dat moment gebeurt, is dat de DNS-binding van de twee slots wordt omgedraaid. Deze functionaliteit zou je ook kunnen realiseren door twee Azure Storage-accounts te maken, waarbij je een custom DNS naar de ene of de andere laat verwijzen. Dit zal waarschijnlijk een handmatige actie zijn in de portal van de domain provider. Maar let op: het automatiseren van deze stap is best lastig.

Deployment-opties

Zoals een goede ontwikkelaar betaamt, breng je jouw applicatie niet met de hand naar productie. Je gebruikt tools om een CI/CD-pipeline in te richten en zo op een gecontroleerde manier je applicatie live te krijgen. Zowel Web Apps als Azure Storage hebben goede ondersteuning voor deployment vanuit Visual Studio, TFS en Azure DevOps (voormalig VSTS). Je applicatiecode op je hosting service krijgen is geen probleem, maar natuurlijk zit ook hier de devil in the details.

Zoals ik hierboven al beschreef, hebben Web Apps veel ingebouwde features. En die features moeten in het Azure Storage-scenario met andere services worden ingericht. Om dit voor elkaar te krijgen moet je meer in je release pipeline stoppen. Ik heb namelijk nog geen ARM-ondersteuning voor Static website hosting in een Azure Storage-account gevonden. En ook PowerShell wordt nog niet ondersteund. Op dit moment zul je dus een andere manier moeten vinden om je Storage Account te configureren met Static website hosting. Ik vermoed dat deze zaken zijn opgelost op het moment dat Static website hosting for Azure Storage naar General Available gaat.

Prijs vergelijk

En dan nu de aloude Hollandse vraag: wat kost het? Een lastige vraag, want de daadwerkelijke kosten zijn in dit geval natuurlijk moeilijk te voorspellen. Je betaalt namelijk naar gebruik. Toch een indicatie? Gebruik dan de Azure Price Calculator.

Microsoft adviseert om voor productietoepassingen minstens een standaard tier App Service te gebruiken. De goedkoopste is een S1 met Linux. Om gebruik te maken van de SLA, waarmee 99,95% uptime gegarandeerd wordt, moet je twee instanties van deze service hebben draaien. Volgens de price calculator kom je dan uit op zo’n 117 euro per maand.

Het rekensommetje voor Azure Storage is wat lastiger. De prijs is namelijk afhankelijk van het aantal operaties dat we doen en de hoeveelheid data die over de lijn gaat.

Laten we uitgaan van een makkelijk scenario. Ik heb een standaard Angular-project gegenereerd. Na het bouwen levert dit een pakketje van zeven files op die samen 3.05 MB groot zijn.

We gaan uit van 100 gebruikers per minuut die onze site gaan bezoeken. Daarmee worden er per maand 730 uur x 60 minuten x 100 gebruikers x 7 files = 30.660.000 leesoperaties gedaan. Volgens de Azure Price Calculator kom je dan uit op nog geen 30 euro. Dat is nogal een verschil!

Wanneer wel en wanneer niet?

Hoewel het kostenverschil groot is tussen een Web App en Static website hosting voor Azure Storage is het niet altijd gunstig Static website hosting in te zetten. In de projecten waar ik clientside-applicaties heb gezien, werden deze allemaal ondersteund door webservices die op een Web App draaiden. Er werd dan een App Service Plan gebruikt, waarop zowel de service als de frontend-applicatie gehost werd. Het zou gek zijn om dan een de frontend te verhuizen naar een extra storageaccount, waardoor je kosten oplopen.

Maar de wereld is in beweging en backend-services worden lang niet meer alleen op een Web App gehost. Het is goed denkbaar dat in jouw project je tegen services aanpraat die gehost worden in Azure Service Fabric, Azure Functions of een container. In dat geval heb je voor je backend-services geen kosten voor een App Service Plan en is het gunstig om eens te kijken naar Static website hosting voor Azure Storage.

Mijn conclusie

Mijn eerste indruk van Static website hosting voor Azure Storage is positief. De features die ik veel gebruik in Web Apps worden ondersteund, al zijn sommige features lastiger te configureren dan anderen. Het feit dat het een No-Ops-oplossing is, spreekt mij ook enorm aan. Hoe minder onderhoud een service nodig heeft, hoe beter, nietwaar?!

Daarnaast is er een enorm verschil in kosten tussen een Web App en Static website hosting voor Azure Storage. Hier kun je in sommige situaties je voordeel mee doen. Ik blijf deze nieuwe feature dan ook goed in de gaten houden!

Over Bas

Bas Peeters is Craft Expert van Team Azure Development binnen Craft, hét groeiprogramma voor IT'ers (powered by Centric). Wil je zijn blog volgen? Schrijf je in voor de Craft-update

Wil je meer weten over Craft, hét groeiprogramma voor IT'ers? Neem een kijkje op de website

       
Schrijf een reactie
  • Captcha image
  • Verzenden