Z uporabo rešitve Azure Functions lahko podjetja prek dogodkovnih sprožilcev (HTTP, Service Bus, časovniki) močno poenostavijo gradnjo API-jev in asinhrono obdelavo podatkov. Ta brezstrežniška (serverless) rešitev omogoča zanesljivo avtomatizacijo procesov in optimizacijo stroškov, saj v celoti odpravi potrebo po ročnem upravljanju infrastrukture.

Azure Functions je brezstrežniška (serverless) rešitev, ki omogoča razvoj zmogljivih aplikacij z manj kode in enostavnejšo infrastrukturo. Namesto da bi morali ob povečanju ali zmanjšanju obremenitve ročno prilagajati zmogljivost strežnikov, se Azure Functions samodejno prilagajajo obremenitvi in skalirajo glede na potrebe aplikacije - vse do vnaprej določene omejitve.

Splošne lastnosti

Azure Functions so privzeto stateless, kar pomeni, da si med posameznimi zagoni funkcije ne zapomnijo stanja oziroma sprememb, ki so se zgodile med izvajanjem. Če potrebujemo stateful funkcije, lahko uporabimo možnost Durable Functions, ki omogoča ohranjanje stanja in izvajanje bolj kompleksnih procesov. 
Ker so Azure Functions serverless, je eden od možnih stranskih učinkov ta, da se funkcije ob daljšem obdobju neaktivnosti lahko ustavijo. Ko je funkcija ponovno poklicana, mora Azure ponovno vzpostaviti potrebno izvajalno okolje, kar lahko povzroči tako imenovani Cold Start.
To pomeni, da lahko na primer API, ki temelji na Azure Functions, ob prvem klicu po daljšem obdobju neaktivnosti potrebuje nekoliko več časa za odgovor kot običajno.
To lahko rešimo tako, da v Azure Portalu pod »Scale and concurrency« nastavimo možnost »Always-ready instances«. S tem lahko določimo število instanc, ki bodo za določeno funkcijo oziroma vrsto funkcije vedno pripravljene na izvajanje.
Na ta način zmanjšamo verjetnost Cold Startov, saj Azure-u ni treba vsakič znova vzpostavljati izvajalnega okolja za neaktivno funkcijo.
Seveda pa ima takšna nastavitev tudi svojo ceno. Always-ready instance namreč pomenijo, da določeno število instanc ostaja ves čas pripravljeno na izvajanje, kar posledično prinese nekoliko višje stroške.

Sprožilci (Triggers)

Triggers oziroma sprožilci določajo, kdaj in na kakšen način se Azure Function izvede. Funkcija se lahko na primer sproži ob prejemu HTTP zahtevka, dodanem sporočilu v vrsto (queue), spremembi podatkov v bazi ali ob določenem časovnem intervalu.
Vsaka Azure Function ima lahko en sprožilec, ki določa dogodek, na katerega se funkcija odzove.

HTTP sprožilec

HTTP sprožilec je eden najosnovnejših sprožilcev, saj Azure Function izpostavi kot HTTP endpoint, ki ga lahko pokličemo z običajno HTTP zahtevo. Uporabimo ga lahko na primer za izdelavo API-jev, prejemanje podatkov iz drugih aplikacij ali obdelavo zahtevkov uporabnikov.

[Function("HttpFunction")]

public IActionResult Run([HttpTrigger(AuthorizationLevel.Anonymous, "get")] HttpRequest req)

{

return new OkObjectResult($"Welcome to Azure Functions!");

}

Pri HttpTriggerju lahko z nastavitvijo AuthorizationLevel določimo, kdo lahko dostopa do funkcije oziroma jo lahko pokliče. S tem lahko nadzorujemo, ali je funkcija javno dostopna ali pa je za njen klic potrebno ustrezno preverjanje oziroma ključ.

Service Bus sprožilec

Service Bus sprožilec omogoča, da se Azure Function samodejno izvede, ko je v Azure Service Bus vrsti (queue) ali temi (topic) na voljo novo sporočilo.
To je uporabno predvsem pri asinhroni obdelavi sporočil, saj funkciji ni treba neprestano preverjati, ali je prispelo novo sporočilo. Ko se sporočilo pojavi, ga sprožilec zazna in zažene funkcijo, ki ga lahko nato obdela.

[Function(nameof(ServiceBusReceivedMessageFunction))]

[ServiceBusOutput("outputQueue", Connection = "ServiceBusConnection")]

public string ServiceBusReceivedMessageFunction(

    [ServiceBusTrigger("queue", Connection = "ServiceBusConnection")] ServiceBusReceivedMessage message)

{

    _logger.LogInformation("Message ID: {id}", message.MessageId);

    _logger.LogInformation("Message Body: {body}", message.Body);

    _logger.LogInformation("Message Content-Type: {contentType}", message.ContentType);

    var outputMessage = $"Output message created at {DateTime.Now}";

    return outputMessage;

}

Časovni sprožilec

Časovni sprožilec omogoča, da se Azure Function samodejno izvede ob določenem času oziroma v določenih časovnih intervalih. Urnik izvajanja določimo s CRON izrazom, zato lahko funkcijo nastavimo na primer tako, da se izvede vsakih 5 minut, vsak dan ob določeni uri ali enkrat tedensko.
Uporaben je predvsem za periodična opravila, kot so čiščenje podatkov, generiranje poročil, preverjanje stanja sistemov ali izvajanje različnih ozadnih procesov.

[Function(nameof(TimerFunction))]

[FixedDelayRetry(5, "00:00:10")]

public static void Run([TimerTrigger("0 */5 * * * *")] TimerInfo timerInfo,

    FunctionContext context)

{

    var logger = context.GetLogger(nameof(TimerFunction));

    logger.LogInformation($"Function Ran. Next timer schedule = {timerInfo.ScheduleStatus?.Next}");

}

Ostali sprožilci

Na voljo je veliko različnih sprožilcev, vendar so zgoraj našteti med bolj uporabnimi za začetek. Ostale sprožilce in podrobnejšo dokumentacijo si lahko ogledate na https://learn.microsoft.com/en-us/azure/azure-functions.

Scenariji

V nadaljevanju bom predstavil nekaj primerov oziroma scenarijev, kjer lahko uporabimo Azure Functions.

Scenarij 1: REST API

Predstavljajmo si spletno trgovino, kjer uporabnik odda naročilo. Ob potrditvi naročila aplikacija pošlje HTTP zahtevek na Azure Function. Funkcija preveri podatke naročila, ga shrani v bazo in po potrebi sproži nadaljnjo obdelavo, na primer pošlje potrditveno e-pošto ali ustvari račun.
Prednost takšnega pristopa je, da nam ni treba vzdrževati strežnika, ki bi ves čas čakal na nova naročila. Azure Functions se samodejno prilagajajo številu zahtevkov, zato lahko brez večjih sprememb obravnavamo tako nekaj naročil na uro kot tudi velik porast naročil.

Scenarij 2: Service Bus

Predstavljajmo si, da obdelava naročila v API-ju traja predolgo, zato ne želimo, da uporabnik čaka na zaključek celotnega procesa. V tem primeru lahko uporabimo HTTP sprožilec, ki sprejme naročilo in ga zapiše v Service Bus Queue.
Nato Service Bus sprožilec zazna novo sporočilo v vrsti in zažene Azure Function, ki naročilo obdela v ozadju. Na ta način lahko API uporabniku hitro odgovori, medtem ko se obdelava naročila izvede asinhrono in neodvisno od začetnega zahtevka.

Scenarij 3: Preverjanje Dead-letter Queue

Predstavljajmo si, da želimo ob začetku delovnega dne preveriti, ali so se v Service Bus Dead-letter Queue čez noč znašla sporočila, ki jih ni bilo mogoče uspešno obdelati.
Za to lahko uporabimo Časovni sprožilec, ki se vsak delovni dan ob določeni uri zažene. Funkcija preveri Dead-letter Queue in, če najde kakšno sporočilo, o tem obvesti odgovorno ekipo, na primer prek e-pošte ali Teamsa.
Na ta način lahko avtomatiziramo jutranje preverjanje in hitro zaznamo sporočila, ki zahtevajo dodatno obravnavo.

Lenart Svetek

Front - end programer, študent

lenart.svetek@kompas-xnet.si

Imate dodatna vprašanja?

Za več informacij smo vam vedno z veseljem na voljo. Pišite nam na info@kompas-xnet.si ali nas pokličite 01 5136 990.