Azure Functions eller Logic Apps? Så har AI-stödd utveckling förändrat vår avvägning

Valet mellan Azure Functions eller Logic Apps är inte nytt, men svaret förändras. När AI-stödd utveckling, Flex Consumption och mognare testverktyg förskjuter förutsättningarna, behöver “when to use what” ställas om mot ett uppdaterat underlag. På Contica har vi gjort just det. Här är resonemanget bakom hur vi väljer idag, och vad som har förändrats.

Detta inlägg kommer från Moln & Mackor

Sedan ett par månader tillbaka kör vi internt ett format vi kallar Moln & Mackor. Varje onsdagsmorgon presenterar någon kollega något tekniskt de vill dela med sig av. Syftet är kunskapsspridning internt, men innehållet är ofta så bra att det förtjänar en bredare publik. Från och med nu delar vi minst ett Moln & Mackor externt varje månad, i artikelform eller som video. Det här är vårt första inlägg på temat, baserat på en presentation om hur vi tänker kring valet mellan Azure Functions och Logic Apps.

When to use what är fortfarande rätt fråga

Logic Apps har varit Conticas default i åratal, av goda skäl. Visuell design, ett rikt connector-ekosystem och snabb tid till första körning gör dem starka för en stor del av de flöden vi bygger. De är fortsatt en självklar del av vår leverans.

Det vi gjort är att se över vanan: vad sträcker vi oss efter när inget specifikt krav pekar åt ett annat håll? Tidigare var svaret nästan alltid Logic Apps. När vi tittar på vad som faktiskt ger högst kvalitet, lägst kostnad och bäst utvecklingsupplevelse idag, pekar svaret oftare mot Azure Functions. Frågan är densamma. Underlaget för svaret har förändrats.

Vad har förändrats?

Sex saker har tillsammans förskjutit avvägningen för många av de flöden vi bygger.

1. AI-first utveckling. Vi jobbar allt mer AI-first, med verktyg som Claude och GitHub Copilot som en självklar del av utvecklingsmiljön. Dessa verktyg är väsentligt bättre på att skriva och underhålla C#-kod än att producera workflow.json. Att flytta logiken till ren kod ger betydligt mer hävstång ur den utvecklingsmetodik vi använder dagligen, och den hävstången växer snabbt.
2. Flex Consumption med VNet-stöd. Logic Apps Standard kräver en App Service plan på cirka 1 700 kronor i månaden, ett fast golv som blir tungt för mindre miljöer. Azure Functions kan köras på Flex Consumption, där betalning sker per faktisk körning. Det avgörande är att Flex Consumption stödjer VNet-integration, vilket den klassiska Logic Apps Consumption-modellen inte gjorde. Vi får alltså consumption-prissättning kombinerat med de nätverksuppsättningar vi har som standard. För sporadiska eller event-drivna flöden blir kostnadsbilden påtagligt bättre.
3. Skalning utan manuell tuning. På Flex Consumption försvinner frågan om hur många workflows som ryms på en plan, eller hur belastning ska balanseras mellan instanser. Plattformen sköter det. Det är en återkommande designdiskussion vi inte behöver föra längre.
4. Testbarhet med standardramverk. Automatiserade tester i Logic Apps har varit en återkommande huvudvärk. Vi har gjort flera försök och aldrig riktigt nått hela vägen. Med Functions blir det rakt på sak: xUnit eller NUnit, samma testpipelines som för annan .NET-utveckling, och pull request-flöden där varje release kan följas av en testrapport. Vi går från att täcka enskilda mappningar till att kunna täcka hela integrationer.
5. Developer experience. Lokal utveckling i Visual Studio Code är enklare och stabilare med ren kod än med Logic Apps designerns kringutrustning. Färre underliga fel, snabbare iteration, vanliga code review-mönster.
6. Flexibilitet och återanvändning. Vi bygger nu ett internt .NET-bibliotek med byggblock vi använder återkommande: felhantering, retry-logik, loggningsmönster, gemensamma helpers. Det blir ett “Contica-bibliotek” som höjer kvaliteten och sänker leveranstiden över tid. Möjligheten att packa om custom logik som ett återanvändbart NuGet-paket är något Logic Apps-utveckling inte erbjuder på samma sätt.

När väljer vi Logic Apps?

Logic Apps är rätt val när integrationen drar tydlig nytta av dess styrkor. Konkret handlar det om:

• Tunga managed connectors mot system som SAP, Dynamics 365 eller Salesforce, där Logic Apps har färdiga komponenter som hade tagit lång tid att bygga själv.
• B2B och EDI-flöden med AS2, X12 eller EDIFACT, där Logic Apps har specialiserat stöd.
• Triggers som inte finns i Functions, exempelvis “när ett mejl anländer i Outlook”, där Logic Apps löser det per automatik via sin connector. I de fallen är Logic Apps självklart valet, inte något att bygga om i Functions för principens skull.
• Snabb prototypning där visuell översikt skapar mer värde än kodkontroll.
• Flöden där icke-utvecklare ska kunna förstå översikten, exempelvis verksamhet eller förvaltning som behöver insyn utan att läsa kod.

För stora datavolymer fortsätter vi använda Azure Data Factory. Det är ingen förändring där. Data Factory är rätt verktyg för ETL/ELT, bulkflyttar och schemalagd batch-processering över större dataset.

Designen ändras inte, implementationen gör det

En viktig poäng: själva integrationsdesignen ser likadan ut. Receive, map, send. Service Bus i mitten, API Management framför. Samma mönster, samma arkitektur. Det är komponenten som implementerar varje steg som byts ut. En Function ersätter motsvarande Logic App-workflow i flödet, ingenting annat.

För mer avancerade orkestreringar finns Durable Functions, som kan agera workflow-motor med stöd för långkörande processer, väntelägen och checkpoints. Valet mellan vanliga Functions och Durable Functions blir en designfråga per integration: vilken nivå av tillstånd och orkestrering kräver flödet?

Vad händer med loggning och förvaltningsbarhet?

Logic Apps har en stor styrka i sin körhistorik. Vem som helst kan öppna ett run och se exakt vad som hänt, steg för steg. Det är en stark förvaltningsegenskap som vi tar med oss som krav när vi bygger i Functions: ingen integration ska bli en svart låda.

Det betyder en gemensam loggningsstandard, byggd på Azure-native loggning som bas, med möjlighet att koppla på externa verktyg där det behövs. Loggar ska kunna läsas och förstås även av förvaltning, inte bara av den som skrev koden, och fel ska peka tydligt på var och varför något gick snett.

Samma fråga, uppdaterat svar

Det här är inte en stor svängning. Verktygslådan är densamma. Det vi justerar är vad som väger tyngst när vi ställer frågan “when to use what”, och det skiftet öppnar för bättre kostnadseffektivitet, starkare AI-stöd i utvecklingen, riktiga automatiserade tester och en flexibilitet vi tidigare fått tumma på.

Logic Apps är fortsatt rätt verktyg för många integrationer, och kommer att vara det. Skillnaden är att vi ställer frågan med uppdaterat underlag, och att svaret oftare än tidigare landar i Functions.

Vill du veta mer om hur vi arbetar med Azure-integrationer? Läs gärna vår sida om Azure Integration Services eller hör av dig direkt.

Vanliga frågor

Vilket språk använder ni för Azure Functions?

C#. Det är vårt standardspråk i linje med Microsofts rekommendation och hela .NET-stacken. Andra språk kan vara aktuella i specifika fall, men default är C#, vilket också ger bästa möjliga draghjälp av vårt interna .NET-bibliotek.

När använder ni Durable Functions istället för vanliga Functions?

När flödet behöver tillstånd över tid, exempelvis långkörande processer, väntelägen, fan-out/fan-in eller behov av checkpoints för att undvika att hela kedjan körs om vid retry. För enklare event eller messagedrivna flöden räcker vanliga Functions. Valet är en designfråga per integration.

Förändras hur ni designar integrationer?

Nej. Designmönstret med receive, map och send via Service Bus och API Management ligger fast. En Function ersätter helt enkelt motsvarande Logic App-workflow som implementation av varje steg.

Hur säkerställer ni samma förvaltningsbarhet som Logic Apps run history erbjuder?

Genom en gemensam loggningsstandard byggd på Azure-native loggning som bas, med möjlighet att koppla på externa loggningsverktyg där det behövs. Kravet är att loggarna ska vara läsbara även för förvaltning och tydligt peka på vad som gick fel, inte bara skrivna för den som utvecklade integrationen.