Sverige
Azure

Azure Logic Apps vs. Azure Functions Apps

Logic Apps

Microsofts populära molnplattform Azure erbjuder en stor mängd produkter för att utveckla molnbaserade integrationslösningar. En av dessa är Logic Apps, som är ett enkelt sätt att bygga automatiserade arbetsflöden för att integrera och hantera system och data.

Även personer utan större kodvana kan relativt snabbt bygga ett enklare flöde i Logic Apps. Flödena definieras med JSON, men i Azure-portalen kan man grafiskt klicka och dra konnektorer samt konfigurera dem genom att skriva in i fördefinierade fält hur man vill att de ska bete sig. JSON-definitionen genereras då automatiskt.

Ett Logic App-flöde börjar alltid med en trigger. Några vanliga exempel är att flödet ska triggas schemalagt, att det triggas via ett http-anrop, att en fil hamnar i en katalog, eller att ett meddelande hamnar på en prenumeration i en meddelandekö. Sedan kan man, även utan större programmeringsvana, grafiskt konfigurera flödet och bygga in logik. Det finns stöd för de flesta användbara statements som if-else, switch, for each, until med flera.

Här kommer en liten demonstration. Vi definierar ett flöde som, från ett http-anrop där bodyn är en JSON-array med heltal, svarar på anropet med en array som berättar vilka av talen som är jämnt delbara med 5.

Arrayen som skickas in i request-bodyn är: [5, 10, 11]

Arrayen som kommer tillbaka i response-bodyn är:

[

    "The number 5 is divisible by 5.",

    "The number 10 is divisible by 5.",

    "The number 11 is not divisible by 5."

]

image

Azure Functions Apps

Azure Functions Apps kan användas i samma scenario och utföra samma jobb som i exemplet ovan, men utgörs inte av grafiska drag-and-drop-flöden eller JSON-definitioner. En ”function” skrivs i kod och några av språken som går att använda är C#, Java eller Python.

En function är i normalfallet stateless, det vill säga den körs på samma sätt varje gång för en viss input. Det går också att använda Azure Durable Functions, där man även har en ”orkestrerings-funktion” som låter underfunktionen veta vilket ”state” som gäller. Detta skiljer sig från Logic Apps som alltid är stateless.

En Function App utgörs av en eller flera funktioner. Varje funktion har en trigger och kan, precis som i exemplet med Logic Apps, symbolisera ett flöde.

Vilket alternativ ska väljas?

Det finns för- och nackdelar i olika scenarion med de olika alternativen. Det här inlägget fokuserar på det scenario där man vill skapa ett relativt enkelt flöde, som triggas och utför arbete enligt någon fördefinierad logik.

Om man är van vid något av programspråken som stöds av Azure Functions, har man inte lika stor nytta av den ”snälla” inlärningskurvan som Logic Apps erbjuder. Logic Apps är visserligen mer nybörjarvänligt, men om man vill ha logik som är mer komplex än grundläggande if-villkor, for-loopar eller switchar blir det snart krångligt att bygga och överblicka hela logiken i en Logic App.

Logic Apps blir ofta dyrare än Function Apps, speciellt för mer komplicerade scenarion än de allra enklaste flöden. Det lättaste sättet att komma i gång med Logic Apps är att välja en consumption-based prissättning. Det innebär att man betalar en liten kostnad för varje ”action” som sker i varje körning. I demonstrationen på föregående sida betalar man alltså för varje gång som en liten färgad ruta processar information – i for-each-loopen kan man multiplicera det med antalet element i arrayen. Multiplicera återigen med antalet gånger flödet triggas, och vi kan föreställa oss hur kostnaden växer oväntat snabbt.

En Function App kan man välja att köra via en App Service Plan med fast månadskostnad, lägga alla sina funktioner/flöden på samma plan och ändå inte betala mer oavsett hur komplex logiken blir, hur lång tid det tar eller hur ofta funktionen triggas. Detta gäller förstås upp till en viss gräns, sedan behöver man uppgradera planen. Men i de flesta fall är de lägre servicenivåerna tillräckliga.

Ju enklare logik och ju färre loopar flödet innehåller, desto större anledning att välja Logic Apps. Det går snabbare att sätta upp, och färre logiska moment innebär en lägre kostnad om man bara betalar per ”consumption”.

Om flödet bara förväntas köras några enstaka gånger per dag, blir det förmodligen billigare att sätta upp en Logic App och bara betala för varje action i flödet som körs. Men ju oftare flödet ska köras, desto större anledning att välja Azure Functions.

I en Logic App är det enkelt att gå till en tidigare körning och följa processen och logiken som utfördes i efterhand. Grundbeteendet är att varje steg i flödet loggar ut information för varje körning, så att man får en grafisk, lättläst logg, utan att behöva programmera in dess beteende i förväg. Om det finns krav på att flödet ska kunna köras snabbt, blir detta däremot en enorm nackdel. Om tiden är kritisk, om flödet ska kunna triggas många gånger samtidigt eller med korta intervall, eller om det är viktigt att ett anrop får snabb respons, är Function Apps ett bättre alternativ.

Naturligtvis går det att få ut informativa loggar från Function Apps, men man behöver programmera in loggningsbeteendet själv. Det krävs också att man har lite kunskap om Application Insights, som är den tjänst som Azure erbjuder för att övervaka Function Apps och många andra tjänster.

Sammanfattning

Logic Apps är ett nybörjarvänligt sätt att sätta upp enkla flöden med lägre krav på snabb körtid. De passar bra för scenarion där man vill slippa skriva kod och kunna ha möjlighet att följa körningarna grafiskt i efterhand. De bör användas när flödet inte behövas triggas så ofta och har en enkel logik.

Function Apps erbjuder större frihet att bygga mer komplexa flöden i olika programspråk. De passar bra för scenarion där flödet behöver köras snabbt, ofta, med mer komplicerad logik.

test

Inläggsförfattare