Azure Logic Apps vs. Azure Functions Apps

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.