Azure Functions är en del av Microsofts serverlösa beräkningstjänst. Det låter dig helt enkelt köra små kodbitar som svar på händelser utan att du själv behöver hantera servrarna.
Till exempel kan en funktion köras när en HTTP-begäran kommer in, när en fil laddas upp till lagring eller när en schemalagd tid uppnås.
”Serverlöst” betyder inte nödvändigtvis att det inte finns några servrar. Det betyder att Azure sköter infrastrukturen åt dig. Azure hanterar etablering, skalning och underhåll bakom kulisserna.
I den här guiden går jag igenom byggstenarna, det vill säga triggers, bindningar, värdalternativ och ett praktiskt exempel för att få dig igång.
Vad är Azure Functions?
En Azure Function är helt enkelt en liten kodsnutt som körs när den triggas av en händelse du väljer. Du skriver logiken, och Azure sköter resten åt dig.
Det finns tre idéer som definierar den här modellen.
- Den händelsedrivna exekveringen gör att koden bara körs när något händer, inte hela tiden.
- Den automatiska skalningen gör att Azure kan lägga till eller ta bort beräkningsresurser baserat på efterfrågan.
- Den förbrukningsbaserade prissättningen gör att du, i vissa värdplaner, bara betalar för den tid din kod faktiskt körs.
Helst gör en enskild funktion en sak, som att ändra storlek på en bild eller bearbeta ett meddelande. En Function App är behållaren som rymmer en eller flera funktioner. Den hanterar delade inställningar, som konfiguration och distribution, för alla funktioner i den.
Hur Azure Functions fungerar
En funktions livscykel kan ses följa ett enkelt mönster enligt följande:
- En händelse inträffar, till exempel en filuppladdning eller ett HTTP-anrop.
- En trigger upptäcker händelsen och startar funktionen omedelbart.
- Funktionen kör sin kod.
- Bindningarna kopplar funktionen till andra tjänster som läser indata eller skickar utdata som behövs.
- Azure hanterar beräkningsresurserna bakom den här processen, och detta är förstås baserat på din valda värdplan.
Det här flödet är i stort sett detsamma oavsett språk eller värdalternativ. Bara triggern, koden och bindningarna ändras.
Triggers i Azure Functions
Varje funktion har exakt en trigger. Triggern definierar exakt hur funktionen startar. Här är de vanligaste typerna som du bör känna till:
- HTTP-trigger: Kör en funktion när den tar emot en HTTP-begäran. Vanligt vid byggande av API:er.
- Timer-trigger: Kör en funktion enligt ett schema, till exempel varje timme eller en gång per dag.
- Blob Storage-trigger: Kör en funktion när en fil läggs till eller ändras i Azure Blob Storage.
- Kö-trigger: Kör en funktion när ett nytt meddelande anländer i en kö.
- Event Hub-trigger: Kör en funktion som svar på en ström av händelser. Mycket användbart för stora datamängder.
- Cosmos DB-trigger: Kör en funktion när dokument skapas eller uppdateras i en Cosmos DB-behållare, med hjälp av dess Change Feed.
- Service Bus-trigger: Kör en funktion som svar på meddelanden från en Azure Service Bus-kö eller -ämne, vanligt vid företagsmeddelanden och för att avkoppla system.
- Durable Functions: En utökning av Azure Functions som låter dig skriva tillståndsfulla funktioner i en serverlös miljö för att orkestrera komplexa arbetsflöden i flera steg.
Bindningar i Azure Functions
Jag tycker att triggers och bindningar ofta blandas ihop, men även om de ser lika ut gör de helt olika jobb. En trigger startar en funktion, medan en bindning kopplar funktionen till data genom att läsa in den eller skicka ut den.
Indatabindningar
Här ger du din funktion data utan att skriva anpassad integrationskod. Till exempel kan en funktion läsa en post från en databas automatiskt bara genom att deklarera bindningen.
Utdatabindningar
Detta låter dig skicka din funktions resultat någon annanstans. Du kan till exempel använda utdatabindningar för att skriva ett bearbetat meddelande till en kö.
Här är ett exempel som hjälper till: En Blob Storage-trigger startar en funktion när en bild laddas upp. En utdatabindning sparar sedan den ändrade bilden i en annan lagringsbehållare. Bindningarna hanterar lagringsanslutningarna, och ingen manuell lagringsklientkod behövs.
Så skapar du din första Azure Function
Här är ett enkelt exempel på en mycket enkel HTTP-triggad funktion som returnerar en hälsning. Flödet är:
- Skapa en Function App. Detta är behållaren för din funktion i Azure.
- Välj en runtime och välj språket du vill koda i.
- Lägg till en ny funktion i din Function App.
- Välj HTTP-trigger så att funktionen kan svara på webbförfrågningar.
- Lägg till en enkel funktion som läser ett namn från begäran och returnerar ”Hej, [name].”
- Kör och testa funktionen med de inbyggda testverktygen eller skicka helt enkelt en begäran från din webbläsare.
- Distribuera den till Azure så att den är live och nåbar.
Jag gjorde det här exemplet medvetet litet för att visa mönstret och låta din kreativitet göra resten.
Språk som stöds av Azure Functions
Azure Functions stöder många språk, såsom:
- C#
- JavaScript/TypeScript
- Python
- Java
- PowerShell
Stöd och utvecklingsmodeller kan variera beroende på språk och version. Därför rekommenderar jag att du kontrollerar den aktuella Azure-dokumentationen innan du startar ett nytt projekt eftersom dessa detaljer ändras ofta.
Värdalternativ för Azure Functions
Alla Azure Functions körs inte på samma sätt. Azure erbjuder flera värdplaner, var och en med olika kompromisser. Rätt val beror på ditt fall. De viktigaste avvägningarna är:
- Skalning: Vissa planer skalar automatiskt och omedelbart, medan andra kräver lite mer manuell styrning.
- Uppstartsbeteende: Vissa planer håller funktionerna ”varma”. Det betyder helt enkelt att de är redo att köras direkt, medan andra startar funktioner vid behov.
- Nätverk: Vissa planer stöder avancerade nätverksfunktioner som att ansluta till ett privat virtuellt nätverk, medan andra inte gör det.
- Kostnad: Prissättningsmodellerna skiljer sig avsevärt, från betalning per körning till fasta månadskostnader.
Skalning och kalla starter i Azure Functions
Två ytterligare koncept är viktiga när din funktion körs i produktion. Dessa är:
Automatisk skalning
Här övervakar Azure belastningen på din funktion och när efterfrågan ökar lägger den till fler beräkningsinstanser, och när efterfrågan sjunker tar den bort dem. Du behöver inte hantera detta manuellt.
Kalla starter
Om en funktion inte har körts på sistone kan den behöva en stund för att starta innan den kan hantera en ny begäran. Denna fördröjning kallas en kall start. Vissa värdplaner minskar eller undviker detta genom att hålla instansen varm, som nämnts.
Vanliga användningsfall för Azure Functions
Den händelsedrivna modellen passar många vardagliga problem som du kan stöta på. Särskilt:
API:er och webhooks
Detta för att hantera inkommande HTTP-begäranden utan att behöva köra en fullständig webbserver dygnet runt.
Fil- och bildbehandling
Detta hjälper till att trigga en funktion när en fil landar i lagring, och sedan ändra storlek, konvertera eller bara skanna den.
Schemalagda jobb
Detta hjälper till att köra städuppgifter, rapporter eller påminnelser på en timer utan behov av en dedikerad alltid-på-server.
Databearbetningspipelines
Detta hjälper till att bearbeta meddelanden eller händelser när de anländer, ett steg i taget.
IoT och händelsebearbetning
Detta hjälper till att hantera stora volymer av sensor- eller enhetsdata när de strömmas in.
Bakgrundsuppgifter
Detta avlastar långsamt eller sporadiskt arbete, som att skicka e-post, så att det inte blockerar din huvudapplikation.
Övervakning och felsökning av Azure Functions
När en funktion är live behöver du insyn i hur den presterar.
Du kan till exempel se loggarna som sparar vad som hände under varje körning, vilket är mycket praktiskt för felsökning. Du kan också kontrollera Application Insights i Azure-verktygen, som spårar prestanda, begäranden och fel på en central plats.
Du bör också spåra körningsfel så att du vet när och varför en funktion inte slutfördes. Övervakning av prestanda hjälper dig dessutom att upptäcka långsamma funktioner innan de ens blir ett problem, och återförsöksbeteende kan förstås konfigureras så att misslyckade körningar försöker igen automatiskt.
Slutsats
Azure Functions ger dig ett sätt att köra kod som svar på händelser, utan att behöva hantera servrarna under. Triggern avgör när en funktion startar. Bindningarna, å andra sidan, gör det enkelt att koppla den funktionen till andra tjänster utan extra integrationskod.
När du går från en enkel testfunktion till något som körs i produktion blir val av värd och skalning mycket viktigare. Rätt plan påverkar kostnad, men också hastighet och tillförlitlighet.
Azure Functions är en del av Microsofts serverlösa beräkningstjänst. Det låter dig helt enkelt köra små kodbitar som svar på händelser utan att du själv behöver hantera servrarna.
Till exempel kan en funktion köras när en HTTP-begäran kommer in, när en fil laddas upp till lagring eller när en schemalagd tid uppnås.
”Serverlöst” betyder inte nödvändigtvis att det inte finns några servrar. Det betyder att Azure sköter infrastrukturen åt dig. Azure hanterar etablering, skalning och underhåll bakom kulisserna.
I den här guiden går jag igenom byggstenarna, det vill säga triggers, bindningar, värdalternativ och ett praktiskt exempel för att få dig igång.
Vad är Azure Functions?
En Azure Function är helt enkelt en liten kodsnutt som körs när den triggas av en händelse du väljer. Du skriver logiken, och Azure sköter resten åt dig.
Det finns tre idéer som definierar den här modellen.
Helst gör en enskild funktion en sak, som att ändra storlek på en bild eller bearbeta ett meddelande. En Function App är behållaren som rymmer en eller flera funktioner. Den hanterar delade inställningar, som konfiguration och distribution, för alla funktioner i den.
Hur Azure Functions fungerar
En funktions livscykel kan ses följa ett enkelt mönster enligt följande:
Det här flödet är i stort sett detsamma oavsett språk eller värdalternativ. Bara triggern, koden och bindningarna ändras.
Triggers i Azure Functions
Varje funktion har exakt en trigger. Triggern definierar exakt hur funktionen startar. Här är de vanligaste typerna som du bör känna till:
Bindningar i Azure Functions
Jag tycker att triggers och bindningar ofta blandas ihop, men även om de ser lika ut gör de helt olika jobb. En trigger startar en funktion, medan en bindning kopplar funktionen till data genom att läsa in den eller skicka ut den.
Indatabindningar
Här ger du din funktion data utan att skriva anpassad integrationskod. Till exempel kan en funktion läsa en post från en databas automatiskt bara genom att deklarera bindningen.
Utdatabindningar
Detta låter dig skicka din funktions resultat någon annanstans. Du kan till exempel använda utdatabindningar för att skriva ett bearbetat meddelande till en kö.
Här är ett exempel som hjälper till: En Blob Storage-trigger startar en funktion när en bild laddas upp. En utdatabindning sparar sedan den ändrade bilden i en annan lagringsbehållare. Bindningarna hanterar lagringsanslutningarna, och ingen manuell lagringsklientkod behövs.
Så skapar du din första Azure Function
Här är ett enkelt exempel på en mycket enkel HTTP-triggad funktion som returnerar en hälsning. Flödet är:
Jag gjorde det här exemplet medvetet litet för att visa mönstret och låta din kreativitet göra resten.
Språk som stöds av Azure Functions
Azure Functions stöder många språk, såsom:
Stöd och utvecklingsmodeller kan variera beroende på språk och version. Därför rekommenderar jag att du kontrollerar den aktuella Azure-dokumentationen innan du startar ett nytt projekt eftersom dessa detaljer ändras ofta.
Värdalternativ för Azure Functions
Alla Azure Functions körs inte på samma sätt. Azure erbjuder flera värdplaner, var och en med olika kompromisser. Rätt val beror på ditt fall. De viktigaste avvägningarna är:
Skalning och kalla starter i Azure Functions
Två ytterligare koncept är viktiga när din funktion körs i produktion. Dessa är:
Automatisk skalning
Här övervakar Azure belastningen på din funktion och när efterfrågan ökar lägger den till fler beräkningsinstanser, och när efterfrågan sjunker tar den bort dem. Du behöver inte hantera detta manuellt.
Kalla starter
Om en funktion inte har körts på sistone kan den behöva en stund för att starta innan den kan hantera en ny begäran. Denna fördröjning kallas en kall start. Vissa värdplaner minskar eller undviker detta genom att hålla instansen varm, som nämnts.
Vanliga användningsfall för Azure Functions
Den händelsedrivna modellen passar många vardagliga problem som du kan stöta på. Särskilt:
API:er och webhooks
Detta för att hantera inkommande HTTP-begäranden utan att behöva köra en fullständig webbserver dygnet runt.
Fil- och bildbehandling
Detta hjälper till att trigga en funktion när en fil landar i lagring, och sedan ändra storlek, konvertera eller bara skanna den.
Schemalagda jobb
Detta hjälper till att köra städuppgifter, rapporter eller påminnelser på en timer utan behov av en dedikerad alltid-på-server.
Databearbetningspipelines
Detta hjälper till att bearbeta meddelanden eller händelser när de anländer, ett steg i taget.
IoT och händelsebearbetning
Detta hjälper till att hantera stora volymer av sensor- eller enhetsdata när de strömmas in.
Bakgrundsuppgifter
Detta avlastar långsamt eller sporadiskt arbete, som att skicka e-post, så att det inte blockerar din huvudapplikation.
Övervakning och felsökning av Azure Functions
När en funktion är live behöver du insyn i hur den presterar.
Du kan till exempel se loggarna som sparar vad som hände under varje körning, vilket är mycket praktiskt för felsökning. Du kan också kontrollera Application Insights i Azure-verktygen, som spårar prestanda, begäranden och fel på en central plats.
Du bör också spåra körningsfel så att du vet när och varför en funktion inte slutfördes. Övervakning av prestanda hjälper dig dessutom att upptäcka långsamma funktioner innan de ens blir ett problem, och återförsöksbeteende kan förstås konfigureras så att misslyckade körningar försöker igen automatiskt.
Slutsats
Azure Functions ger dig ett sätt att köra kod som svar på händelser, utan att behöva hantera servrarna under. Triggern avgör när en funktion startar. Bindningarna, å andra sidan, gör det enkelt att koppla den funktionen till andra tjänster utan extra integrationskod.
När du går från en enkel testfunktion till något som körs i produktion blir val av värd och skalning mycket viktigare. Rätt plan påverkar kostnad, men också hastighet och tillförlitlighet.