
De Discovery Day eind vorig jaar was voor een groepje Pratorians het moment om zich (opnieuw) te verdiepen in Azure Functions. Hun doel van de Discovery Day was bekijken of Prato kosten kan besparen door bepaalde services in functions op te splitsen en vervolgens evalueren of we dan zonder al te veel nadelen kunnen overgaan naar Azure functions.
Een loonmotor is een typisch voorbeeld van een applicatie met zeer sterk fluctuerende belasting. Het merendeel van de tijd gebeurt er vrijwel niks. Eens de prestaties daarentegen beschikbaar zijn, moeten de lonen zo snel mogelijk betaald worden. Het is zeer inefficiënt om hiervoor zelf de infrastructuur te beheren. Dat is de reden waarom onze Earnie loonmotor volledig in de cloud draait. Momenteel gebruiken we Azure app services. Er zijn echter nog alternatieve manieren om onze loonmotor in de cloud op te zetten, zoals Azure Functions.
Enkel betalen voor gebruik
Azure Functions is een serverloze computer service waarmee je naar aanleiding van gebeurtenissen code kunt uitvoeren zonder expliciet een infrastructuur in te richten of te beheren. Onderhoud is dus niet nodig. En het grote voordeel is dat je enkel betaalt wanneer je het gebruikt. “Tweeënhalf jaar geleden verdiepten we ons ook al eens in Azure Functions”, vertelt Pieter. “Toen hebben we een complete loonbepaling in Azure Functions gedraaid. Azure was toen nog niet ver genoeg ontwikkeld. Sindsdien zijn er grote stappen gezet in wat er standaard wordt aangeboden en ondersteund.”
Beginnen is gemakkelijk
Azure Functions zijn redelijk kleine functies, die één ding doen. Ze krijgen informatie binnen, doen er iets mee, en geven het door aan de volgende functie. Ze reageren op bepaalde triggers of op een bepaald schema (bijvoorbeeld iedere zoveel minuten).
“Je deployt een stukje code en dat werkt”, legt Pieter uit. “Je hoeft verder niet precies te weten hoe en wat. Een function draait niet constant en is alleen online als er iets gebeurt. Als er niets gebeurt, betaal je dus ook niets. Het zorgt er ook voor dat je simpeler kunt programmeren.”
Next steps
Tijdens deze Discovery Day hebben we 1 type bericht onderzocht en zagen dat bepaalde stukken code konden gezien worden als één geheel die dan in een Azure Function verwerkt konden worden.
“Het minst complexe stuk hebben we gebruikt als testcase om te zien hoe makkelijk we dit konden omvormen tot een function. Maar dat is uiteraard niet representatief voor alle andere berichten. Misschien zijn die veel zwaarder, waardoor het meer tijd en geld kost. Toegang tot de database telt ook mee als uitvoeringstijd. De snelheid van je database speelt daardoor ook een rol. Dat moeten we dus zeker nog bekijken. We hebben ook nog niet goed gekeken naar caching en locking en zo zijn er nog een paar dingen.”
Voorzichtig positief
Al bij al durfde de groep toch voorzichtige conclusies trekken aan het eind van de Discovery Day. “Het is mogelijk en werkbaar om onze services over te zetten naar Azure Functions. Op het eerste gezicht lijkt dat ook goedkoper. Maar we kunnen het enkel zeker weten als we de volledige service omzetten, een maand dubbeldraaien, en dan de facturen vergelijken.” To be continued!
Benieuwd naar de andere topics waarmee onze Pratorians al geëxperimenteerd hebben tijdens een Discovery Day? Ontdek het hier.