”No, it isn’t the future of code,” Stiehm said. ”It certainly has a place in the future and will be leveraged to make many applications. It will not replace other ways of creating software because low-code breaks down when the complexity of the solution increases. We saw the same thing with Visual Basis in the ’90s. VB was valuable and a lot of software was written in VB. In the end, it was complexity required by some applications that caused VB to break down and no longer be a good solution. Low code will be the same.”
”The answer is yes and no. Given the difficulty many business users have getting IT to change existing applications and workflows, the use of low-code platforms to solve point problems like tracking work-from-home laptops, makes a lot of sense. But, building large-scale, enterprise-class applications that power entire organizations still requires high-skilled programmers, said Thomas Stiehm, CTO of Coveros, an Agile and DevOps consultancy.”
Is low-code/no-code the future of application development?
Low-code och no-code plattformar som Power Apps och Logic Apps
Just nu råder lite av en hysteri kring low-code och no-code plattformar som Power Apps och Logic Apps där de som antingen tillhandahåller dessa teknologier eller försörjer sig på att implementera lösningar i dem höjder dem till skyarna som det bästa som hänt sen skivat bröd.
Vissa påstår till och med att det helt kommer ersätta utveckling i traditionella utvecklingsspråk och teknologier som C# och Asp.Net Core men så är det naturligtvis inte den här gången heller, och man måste inse att de största förespråkarna antingen tjänar pengar på det, är lite förblindade av hysterin som uppstått, eller vill tro det kommer göra det.
För oss som har varit med ett tag så finns det en hel del likheter mellan Microsofts Power Apps low-code plattform och deras tidigare low-code plattformar som Microsoft CRM, Microsoft Access (som även fanns som webbapp och webbDb services ett tag innan microsoft övergav det), kära gamla Excel som man kunde programmera Visual Basic makron i, och även .Net WinForms desktop och WebForms webb appar som är drag and drop på GUI sidan där man oftast kodade i Visual Basic och även konfigurerade en del.
Det är snarast moderniserade, lite förenklade O365 och Azure anpassade versioner av dessa som Power Apps kanske ska betraktas som.
Power BI sen kan närmast betraktas som storebror till rapporter i Excel och finns även som desktop version, så att den numera även finns på webben förändrar egentligen inte så mycket.
I Power BI kan man kan hämta data från datakällor och skapa snygga dynamiska rapporter, tabeller och diagram, och kommer kanske lösa problemet med att folk fortfarande sitter och gör egna rapporter i Excel som skickas hit och dit inom företaget nu när det finns på webben.
Power Automate är efterföljaren till SharePoint designer för verksamhetsflöden och kommer bli standard för att automatisera verksamhetsflöden i Sharepoint i framtiden.
Power Automate kan vid en första anblick få det att se ut som om det ger användarna betydligt större möjligheter är gårdagens low-code automatiseringsplattformar som SharePoint designer, men det gör den egentligen inte utan är snarast ett krav för att dagens low-code automatiseringsplattformar för verksamhetsflöden ska bli lika användbara som gårdagens när man vill automatisera händelser och arbetsflöden mellan olika datakällor på verksamhetsnivå.
I dagens komplexa IT-miljö med hundratals olika datakällor man kan behöva ansluta till krävs nog Power Automate för att en low-code automatiseringsplattform för verksamhetsflöden ska vara användbar för organisationer som använder O365, Dynamics365 och SharePoint.
Virtual chat bots tänker jag inte gå in på desto mer men den erbjuder ett enklare sätt att göra vanliga chat bots på och kan vara användbar för supportavdelningar.
Tolka även uttrycket ”enterprise grade low-code plattform” på rätt sätt, för det innebär inte att man kan eller rättare sagt ska göra allt i dem, utan att det som är lämpat att göra i dem blir tillräckligt bra, stabilt och välfungerande för att ett företag ska kunna lita på att det fungerar och går att använda till mindre komplexa verksamhetsbehov.
Till exempel Excel kan sägas vara ett ”enterprise grade” kalkylprogram men bara därför så ska man inte försöka göra hur avancerade kalkylapplikationer som helst i den, utan det finns en gräns där det är bättre att bygga upp en professionell applikation i C# och Asp.Net Core, eller rapport i Power BI i stället.
Sen ska vi titta närmare på Power Apps som är utvecklingsdelen och intressantast ur ett utvecklarperspektiv.
Power Apps består av det tre olika apptyperna Canvas Apps, Portal Apps och Model-Driven Apps
”Microsoft Power Apps is an enterprise grade low-code no-code platform that allows users to build professional apps with little to no-code. Through Power Apps, users can build desktop, mobile and tablet based applications using pre-built templates or instead starting from designing the app’s data model, or even by first designing the app’s user interface. Power Apps is one product in Microsoft’s Power Platform.”
A Guide to Microsoft Power Apps Low-Code No-Code Application Development Platform
Canvas Apps är till för att från scratch designa webb och mobilappar och konceptet liknar sättet man utvecklar användargränssnitt på i Asp.Net Webbforms fast lite enklare och mer simplistiskt och kommer antagligen innebära att webb och mobilappar appar som aldrig annars skulle bli gjorda kommer göras.
Model-Driven Apps är till att utveckla datadrivna applikationer mot Microsoft Dynamics365 och man använder färdiga standardkomponenter som det automatiskt genereras ett gui för och är därför hårdare styrt än Canvas apps, och kommer nog innebära att vissa typer av datadrivna applikationer som det annars inte funnits tid att göra kommer bli gjorda.
Portal apps är webbportaler som säkert kommer leda till att många mindre komplexa webbportaler som annars aldrig blivit gjorda kommer göras, allt från temporära projekt eller eventsajer till enklare avdelningsajter, eller nödlösningar i väntat på att få tid eller budget för en professionell lösning.
Dessa kommer däremot inte ersätta professionell utveckling av mer komplexa applikationer i Asp.Net Core, Blazor och C# för det kommer även i fortsättningen vara förstahandsvalet för mer komplexa webbapplikationer precis som det varit tidigare, trots att det funnits och fortfarande finns liknade low-code lösningar.
Power Apps passar bäst för enklare typer av applikationer
”You can build perfectly good applications with “low code” and “no code” platforms. They really can fill a sweet spot for technically-savvy business users who want to build simple web applications or automate straightforward processes. However, these platforms all suffer from the same basic shortcoming: they may be a good fit for simple use cases, but they can make complex problems far more difficult to solve. A simple use case rarely stays that way, especially if an initial implementation is successful. This can give rise to a more ambitious application, requiring capabilities that are not easily achievable in the platform. Over time, creeping complexity can lead to a sprawling mess that everybody is scared to change for fear of breaking something.”
Why “low code” and “no code” platforms are like Japanese knotweed
Råder som sagt lite av en low-code craze i IT-branschen just nu och är inte första gången, men low-code och no-code plattformar har stora begränsningar och nackdelar som man bör vara medveten om innan man använder dem, så man inte använder dem till fel saker eller på fel sätt.
Min syn på saken är ungefär densamma som Ben Morris, som jag tycker är rätt vettig i sina åsikter och är en sorts agilaktig EA arkitekt.
Low-code teknologin Power Apps kommer innebära att enklare webbapplikationer kommer bli av att utveckla som det tidigare kanske inte fanns tid för eller var lönsamt att göra i Asp.Net Core och C#, precis som på den gamla tiden när desktop applikationer fortfarande var vanliga och man gjorde sådana i .Net WinForms, Microsoft Access eller gamla hederliga Excel med Visual Basic som programmeringsspråk.
Sen måste jag göra alla IT-chefer lite besvikna för Power Apps kommer antagligen inte minska behovet av professionella systemutvecklare.
Mer komplexa webbapplikationer kommer fortfarande bäst göras i Asp.Net Core, C# och Blazor, samtidigt som det även kommer behövas professionell utvecklarkompetens för att utveckla även måttligt komplexa applikationer i Power Apps som tidigare inte var lönsamma att göra.
Detta innebär att behovet av professionella systemutvecklare mycket väl kan öka i stället för minska på grund av de nya low-code teknologierna, som inte mer är delvis ersätter utveckling i traditionella utvecklingsplattformar som Asp.Net Core, C# och Blazor.
Power Apps fyller snarast ett hål i marknaden som funnits sedan man gick över från desktop appar till webbapplikationer och mer och mer slutade utveckla enklare applikationer i Excel, Microsoft Access och .Net WinForms där man oftast använde det enklare utvecklingspråket Visual Basic.
Även gamla Asp.Net WebForms teknologin som också var drag and drop på GUI sidan där man oftast använde det enklare utvecklingsspråket Visual Basic för kodningsdelen och även konfigurerade en del var lite grann åt low-code hållet.
Det kan bli så att behovet att mer komplexa applikationer kvarstår samtidigt som det uppstår ett behov av massor av enklare applikationer med Power Apps (för nu är det möjligt) som samtidigt är komplexare än citizen developers kan göra, utan att tillgången på systemutvecklare ökar.
Scenarios där Power apps passar bra att använda sig av
Roberts tumregel för valet mellan Power Apps och Asp.Net Core för utveckling:
Om en applikationer ser ut att kunna bli mer komplex och kräva kodning av många delar även om den görs med Power Apps så ska man utgå i från att det oftast är ett bättre val att implementera den helt i Asp.Net Core, Blazor och C# i stället för med delar i Power Apps.
Nedanstående lista är en rätt bra sammanfattning på de begränsning alla low-code plattformar har i varierande grad, och ger bra vägledning för när man ska eller inte ska använda dem.
För att påminna sig om detta när man är i valet och kvalet mellan att implementera en applikation i t.ex. Power apps eller Asp.Net Core, Blazor och C# har jag tagit fram min tumregel som ni kan följa eller ej.
- Limited customization options: Customization tools are limited in LCDPs that force organizations to adjust the business processes to meet the low-code application capabilities.
- Limited flexibility: As mentioned before, LCDP apps have limited components. When an organization wants to add a specific feature, the drag and drop building blocks may not meet the requirement. In those cases, the business needs to write custom code to enable particular functionality. And these additional codes within LCDPs can be overlooked in terms of maintenance, leading to unexpected outages or bugs.
- Limited integration options: When organizations develop an app using an LCDP, they may face integration issues, especially when they want to migrate legacy applications.
- Security: LCDPs are cloud-based software, developed by users with limited background in information security who don’t have full control of the development process. Therefore, security breaches are a risk in LCDPs and low code applications, especially external facing ones, need to be audited for security issues.
Low/ No code development: What it is, how it works, use cases
Kan även starkt rekommendera er att kolla igenom videon nedan som är gjord av en erfaren Power Apps utvecklare så kommer ni bättre förstå det jag skriver om, och han tar upp många saker som är viktiga att tänka på.
De vanligaste typerna av appar man utvecklar i low-code plattformar som Power Apps är som ni kan se av nedan lista av den enklare typer så Power Apps har ett optimalt användningsområde där det är som lämpligast att använda.
- According to survey, top low code development use cases are
- forms or data-collection apps (58%)
- apps that orchestrate business processes and workflows within apps (49%).
- apps that replace paper, email, or spreadsheets (42%)
- customizing new app UI for current on-premise applications (22%) (Gartner*)
- The average number of apps developed by citizen developers is 13 and web apps are the most common type of citizen development. (Gartner*)
42 Low Code/ No code Statistics in 2021
Enligt undersökningarna så är det alltså olika sorters formulär, orkestreringar av verksamhetsflöden, appar som ersätter papper, mejl eller kalkylark, och moderniserade användargränssnitt för gamla on-prem applikationer som kanske inte lönar sig att satsa för mycket pengar på att modernisera som är det vanligaste användningsområdena.
Detta stämmer rätt väl överens med min syn på vad low-code plattformar som Power Apps är lämpligt att användas till, och allt mer komplext än detta ska man utgå i från är bättre att göra i kod i t.ex. Asp.Net Core, Blazor och C#.
Ett annat användningsområde jag på rak arm kan tänka mig att Power Apps är väl lämpat för är att göra appar för Microsoft Teams, för dessa är ofta av det lite enklare slaget och Teams i sig är skalet runt dem.
Create low-code custom apps for Microsoft Teams
Ni måste också tänka på att Power Apps snabbt börja kostar stora pengar om ni använder premium connectors och har många användare, så förutom att komplexiteten sätter praktiska gränser så sätter även kostnaderna gränser för när det är lönt att använda Power Apps även för enklare appar.
När det gäller citizen developers så tror jag de måste sköta sig helt själva och både lära sig, utveckla och supporta sina egna appar för annars kommer supportavdelningen på ett företag bli så överbelamrade med supportärenden att inget kommer hinnas med.
Sen finns även säkerhetsrisker och GDPR som gör det lite riskabelt med citizen developers och kan innebär extraarbete för driftspersonalen.
Exempel på hur snabbt svårighetsgraden ökar även för måttligt komplexa Power Apps
Så ni ska förstå att Low-code plattformar som Power Apps inte innebär slutet på vanligt systemutveckling eller behovet av professionella systemutvecklare så kan ni läsa igenom nedanstående bloggartiklar som tydligt visar hur snabbt svårighetsgraden ökar när man är tvungen att börja göra bara lite mer komplexa appar i Power Apps, så professionella systemutvecklar behövs fortfarande för allt annat än de mest rudimentära Power Apparna.
Adding real code to the low-code
Microsoft Power Fx utvecklingspråket för Power Apps
”Power Fx is described by Microsoft as a general-purpose, strong-typed, declarative, and functional programming language. It shares the same syntax and functions as Excel, with Microsoft explaining that Power Fx behaves much in the same way its popular spreadsheet application handles formulas.”
Microsoft’s new Power Fx is an open-source language based on Excel
Förr i tiden fanns det utvecklare som gjorde advacerade kalkylappar i Excel genom att skriva macron i visual basic, men detta dog ut eftersom makrona var ett stort säkerhetsproblem, det snabbt blev komplicerat och svårförvaltat med mycket makrokod och Microsoft slutade vidareutveckla makrofunktionalliteten eftersom den tappade mer och mer i popularitet.
”Microsoft Power Fx is the low code language for expressing logic across the Microsoft Power Platform. It is the same language that is at the heart of Microsoft Power Apps canvas apps today and is inspired by Microsoft Excel.”
Power Fx verkar vara någon sorts re-spinn av tanken med visual basic makron för Excel men gjord för deras Power Apps plattform och anpassad för webben i stället, så det har säkert sitt användningsområde för dem som annars gör saker i Excel.
Varför utvecklare oftast inte gillar low-code plattformar
”But developers also fear getting stuck in corners, fiddling with all of the edge conditions, working around all the places where the tool doesn’t do the right thing automatically. They need to handle the glitches, fiddle with undocumented features, and figure out how to satisfy the requests to do things just a bit differently. Developers get trapped between the promise of the sales pitch and the reality that working with low-code tools is often slower and more aggravating than writing your own stack—in other words, the high-code approach.”
9 reasons programmers grow frustrated with the tools that are supposed to save them time
Chefer och ledare är ofta förtjusta i tanken på low-code plattformar och deras löften om att det ska gå så mycket snabbare och lättare att utveckla med dem, men det gäller oftast bara för de enklare typer av appar dessa är optimala att använda för.
Så fort man går utanför gränser där low-code plattformar inte är optimala att använda så blir allt krångligare.
Moderna programmeringspspråk och ramverk som C#, .Net Core och Blazor har dessutom blivit väldigt bra och har många färdiga klassbibliotek och komponenter, så low-code plattformar kan inte konkurrera med dessa annat är för enklare typer av appar inom deras optimala användningsområde.
För att återigen använda Excel som exempel så är Excel alldeles utmärkt att göra vanliga kalkyler i med lite diagram och tabeller, men inte optimalt att göra lite mer advancerade ekonomiappar i som t.ex. ett bokföringsprogram (även om det fanns de som försökte på den gamla visual basic makrotiden), utan då är det bättre att göra en skräddarsydd applikation i ett riktigt utvecklingspråk.
Nedan en lista med de 9 vanligaste skälen till varför utvecklare ogillar low-code plattformar.
- Frustrationen med low-code # 1: Underhållet kan vara svårt.
- Frustrationen med low-code # 2: Alla får samma sak.
- Frustrationen med low-code # 3: En storlek passar ingen.
- Frustrationen med low-code # 4: Ibland är kodning enklare än konfiguration.
- Frustrationen med low-code # 5: Alltför ofta betyder low-code att flyga i blindo.
- Frustrationen med low-code # 6: Ibland behöver du bara infoga en funktion för att städa upp data.
- Frustrationen med low-code # 7: Low-code är ofta ineffektiv.
- Frustrationen med low-code # 8: Erfarenhet önskad.
- Frustrationen med low-code #9: Du är inlåst.
Som ni kan se finns det rätt många nackdelar med low-code plattformar som Power Apps som gör att de mest lämpar sig för enklare applikationer, temporära applikationer eller nödlösningar i väntan på att få budget och resurser att göra en mer komplex långsiktig lösning.
Man kommer rätt snabbt till den gräns där det blir både enklare och bättre att göra applikationen i ett riktigt utvecklingspråk som C#, Asp.Net Core och det utmärkta front-end ramverket Blazor i stället.
Det kan mycket väl vara så att det blir produktivare för en IT-avdelning att renodla all utveckling till att ske i ett riktigt programmeringspråk som Asp.Net Core, C# och Blazor i stället för blanda t.ex. Power Apps för enklare appar, Power Apps + kod för måttligt komplexa appar och kodning för mer komplexa, för det tvingar utvecklarna att jonglera med dubbla eller trippla kompetenser i stället för fokusera på en, och bara det sätter ner produktiviteten.
C#, Asp.Net Core och Blazor Server är en väldigt konkurrenskraftig utvecklingplattform
”However, all those features and more already exist in C#, and have done for years. C# is a powerful, flexible, feature rich language that is easy to learn.”
”But Blazor has already started to show it has potential as a highly efficient and productive programming model outside of its original design—as a direct competitor to JavaScript single page application (SPA) frameworks.”
”The speed of development with this hosting model is obscenely quick, and I mean fast, due to everything being on the server. There is no need for separate API projects, for example, you can just consume application services directly in your components. I was sceptical of Blazor Server at first, but I have to say, I have been really surprised with what it can do.”
What’s behind the hype about Blazor?
Jag har nyligen färdigställ min första Blazor Server app i C# och Asp.Net Core 5 så jag kan bekräfta att det som står i denna artikel stämmer.
Blazor är så pass bra att det bör vara förstahandsvalet som front-end ramverk för Asp.Net Core utvecklare i fortsättningen, och så produktivitetshöjande att det egentligen inte finns några bra skäl att göra mer avancerade applikationer än väldigt enkla i low-code teknologier som power apps.
Low-code plattformar har alltid nackdelar och begränsningar och når ganska snabbt den gräns för komplexitet där det inte längre är optimalt att använda dem, samtidigt som C#, Blazor och Asp.Net Core är så pass bra och välutvecklade att de utökat spannet för när det är bättre att använda dem v.s. low-code plattformar som Power Apps.
Genom att i huvudsak skriva era applikationer I C# och .Net Core blir de portabla mellan molntjänster I så hög grad som möjligt då det enda som kommer skilja är t.ex. Amazons SDK mot dess tjänster.
.Net Core är även open source, har framtiden för sig, stödjer dependency injection, kan paketeras och köras i vanliga linuxbaserade docker kontainrar, är cross plattform, multi- application och stödjer windows, linux och macOS.
Utvecklarna kan out-of-the box utveckla alla typer av appar i Visual Studio & C# med bra stöd för skapandet av olika projekttyper som functions, mobila appar, desktop appar, webbappar med olika front-ends (Razor, Blazor, Angular, React) databasappar (Entity Framework), Webb API’er (WebAPI) och realtids appar (SingnalR).
Skäl till varför det är bättre att skriva integrationer i C# och Azure Functions istället för använda Logic Apps
”If your IT organization consists of mostly developers it might make more sense to use Azure Functions to glue different systems with each other instead of Logic Apps.”
Doing your DevOps stuff with Azure Functions instead of Logic Apps
Det är möjligt att följa vedertagna professionella designprinciper och arbetssätt som separation of concerns, single responsibility principen, MVC, SOLID, DDD, TDD, Unit Tests, CI/CD o.s.v på ett enkelt sätt när man gör saker i Azure Functions vilket det inte är med Logic Apps eller Power Apps, så för organisationer som har tillgång till professionella utvecklare kan det vara att föredra.
Jag tror t.ex. en utvecklare som kan C# och Azure Functions kan slänga ihop en Azure Function på ungefär samma tid som en Logic App i de flesta fall, och fördelen med Azure Functions är att du kan ägna dig åt professionell systemutveckling med dem då inget slår flexibiliten med att utveckla i kod, och det är lättare att både debugga/felsöka, testa, versionshantera och deploya dem enligt CI/CD.
”I’ve always been amazed by the elasticity characteristics of the Logic App engine, however there’s a huge limitation on the scalability of the out-of-the-box connectors. On many projects, we’ve suffered from this limited connector capacity. This blog post series will walk you through the limitations (The bad!), Microsoft’s advised workarounds (The ugly!) and an approach that works great for some connectors (The good!).”
Logic Apps connector performance (1/3) – The bad
När det gäller Logic Apps så är de jämför med Azure Functions rätt långsamma på att transformera, berika och bearbeta information och dessutom är dess connectors throttlade.
Som ni kan se av ovanstående artikelserie är artikelförfattarens lösning för problemet med throttling att man bara ska använda den generella http connectorn och inte de specialiserade connectorerna, vilket innebär att man i princip går miste om den största fördelen med Logic Apps för enklare scenarios och lika gärna kan göra det i kod och Azure Functions i stället när prestanda är ett krav.
”With Azure Durable Functions, you can write stateful workflows in a new function type called an orchestrator function. This orchestration function provides you more control for building workflows than using, for instance, a designer for Microsoft Flow or Logic Apps.”
Is Logic Apps or Durable Functions Best for Your Workflow?
Måste man dessutom börja skriva kod som t.ex ett par Functions för att lösa uppgiften kunde man lika gärna ha gjort allt med Azure Functions i kombination med Durable Functions som kan hantera själva workflow biten.
Logic Apps connectors fyller principiellt samma syfte som SDK’er i .Net Core och C#, så även om man gör saker i C# i stället så finns oftast SDK’s med färdiga ”connectors” i form av klasser och metoder med färdig funktionallitet utöver anslutningsmöjligheten man kan använda sig av när man går mot olika datakällor, och Dataverse SDK’et är ett utmärkt exempel på det.
Microsoft.PowerPlatform.Dataverse.Client
Sen är det inte särkilt svårt att jobba direkt mot REST API’er (vilket många för att inte säga nästan alla system tillhandahåller) från .Net Core och C# med hjälp av HttpClient klassen och Newtonsoft.json heller, så att Logic Apps har färdiga connectors (som i de flesta fall går mot ett REST API…) är inte en så stor skillnad som vissa verkar tro.
Newtonsoft.json innehåller väldigt mycket funktionallitet för alla möjliga scenarios när man ska jobba med json och Newtonsoft.json är ett av de mest använda och supportade Nuget paketen för C# och är även medlem i .Net Foundation, så det klassbibliotektet kommer förbli open source och finnas tillgängligt för alltid och är ett säkert kort.
”Do I agree with the statements above? Of course I do, I wrote them myself! However, this is exercise should not result in concluding that Logic Apps can’t handle the job! Contrary, this is intended to create awareness about potential pitfalls when doing enterprise integration within Logic Apps. Understanding these pitfalls is a first step in designing Logic Apps solutions for robust enterprise integration!”
Logic Apps is not a direct fit for enterprise integration!
Med Logic Apps och Power Apps är det även enkelt att ägna sig åt spagettiprogrammering då man t.o.m får ett drag and drop GUI att göra det i, så det blir lätt spagettiprogrammering om man gör för långa flöden eller advancerade saker i dem om man inte tänker efter.
”In this session, Toon will share his vision on how to achieve a loosely coupled architecture with Logic Apps and why this is so important. The focus will be on re-usability, flexibility, error handling, reliability and monitoring. This session targets both developers and architects.”
Building loosely coupled integrations with Logic Apps
Läser ni ovanstående artikel och kollar på hans föreläsning så kommer ni inse att det krävs mycket mer än man kan tro för att utveckla professionella Logic Apps lösningar.
Det är inte lika enkelt och arbetsbesparande som vissa verkar tro för man måste fortfarande följa vedertagna integrations och designmönster, och det kan till och med vara krångligare än att göra motsvarande saker i kod med Azure Functions sett till alla faktorer.
”Testing Azure Logic Apps is painful! Abort!! If you give up on the idea after reading, this post has served it’s purpose”
Testing Azure Logic Apps is painful! Abort!!
Att testa Logic Apps är inte lika enkelt som att testa Azure Functions och det är bara end-to-end tester som är praktiskt för att testa dem.
Större backend applikationer med ett dussin eller dussintals lite mer advancerade Logic Apps som samverkar och kanske även innehåller en hel del inline kod i javascript är nog inte så kul att underhålla heller.
Logic Apps passar bäst för enkla icke-dataintensiva uppgifter där man kan nyttja deras färdiga connectors och bara skicka vidare datat till exempelvis en service bus eller Azure Functions som bearbetar det om inga krav på nära realtidshantering finns, för om krav på nära realtidshantering finns är det antagligen bättre att bara använda premium plan Azure Functions som alltid är redo och mycket snabbare.
Ser man till hela en applikations livscyckel tror jag faktiskt det kan bli både billigare och bättre att ha kod som förstaval och endast använda Logic Apps till mindre och enklare saker de är väl lämpade för.
”Considering that now Logic Apps Standard runs on top of the Azure Functions runtime, both services are much more similar than they were before. However, depending on the requirements or even personal preferences, an architect or developer might prefer one or the other. Below, I try to provide some decision guidelines summarising the comparison presented above.”
Logic Apps Standard vs Durable Functions: How to Choose? (2021 Update)
Numera finns även Logic Apps Standard som använder functions run-timen och kan utvecklas lokalt i Visual Studio Code så vissa av nackdelarna med traditionella Logic Apps försvinner då, men många blir ändå kvar.
Det förändrar inte min åsikt om att man ska föredra functions och bara använda Logic Apps för enklare scenarios, eller renodla det till enbart functions vilket är fullt möjligt så slipper utvecklarna bolla med multipla plattformar och kan jobba professionellt med lösningar i kod.
Det går inte heller att komma runt det faktum att man kan göra allt i kod men man kan inte göra allt i low-code, så att renodla det till att enbart använda low-code är inte ens ett alternativ.
Några scenarios för integrationer med Azure Functions mot Dynamics 365
Ovanstående video som går igenom scenarios där Azure Functions är lämpliga att använda för Dynamics365 integrations kan vara av intresse för er att se och de scenarios de har identifierat gäller nog i hög grad för andra typer av affärssystem eller applikationer med.
Vill ha en snabb summering av det videon går igenom kan ni läsa deras bloggartikel nedan.
Dynamics 365 CE integrations scenarios with Azure Functions
Läs sedan igenom den pedagogiska förklaringen till hur man utvecklar Azure Functions i Visual Studio Code först för annars kommer ni bli lite förvirrade av de tre bloggartiklarna om hur man använder Azure Functions för Dynamics 365 integrationer.
Quickstart: Create a C# function in Azure using Visual Studio Code
Sen verkar han även ha använt C# Script och inte kompilerad C#.
Azure Functions C# script (.csx) developer reference
De tre artiklarna nedan som går igenom hur man kan gör integrationer mot Dynamics 365 med Azure Functions inte är så lättlästa för den som skrivit dem verkar kunna Dynamics 365 men vara en nybörjare på Azure Functions, så se dem mer som exempel på vad ni skulle kunna använda dem till och inte blueprints.
Integrating Dynamics 365 with Azure Functions – Part 1
Integrating Dynamics 365 with Azure Functions – Part 2
Integrating Dynamics 365 with Azure Functions – Part 3
Orsaken till att de är lite tjorviga och att han skapar Azure Functions projekt i Visual Studio Code för att sedan flytta över koden till ett projekt i Visual Studio som har bättre intellisense verkar bero på att han inte förstått att man kan installera ett program som heter Azure Storage Emulator och starta det för för att kunna köra Azure Functions lokalt på det gamla sättet i Visual Studio 2017 som han måste ha använt.
Debugging Azure Functions Locally
En storage emulator följer även med Azure Functions Core Tools som han redan hade installerat och därför kunde han köra den innifrån Visual Studio Code eller rättare sagt via ett terminal kommando, vilket han hade kunna göra via Developer command prompten i Visual Studio 2017 med och kört i Visual Studio hela tiden.
Work with Azure Functions Core Tools
Azure Functions kan köras i ett kubernetes kluster helt frikopplat från Azure
This project provides: a simple Azure Function with a queue listener, and a HTTP function to add messages to the queue, a set of instructions for deploying the function to a k8s cluster, optionally targeting AKS, a demo of how the KEDA queue-based auto-scaling works.
En annan fördel med Azure Functions är att man enkelt kan göra docker containar och köra dem i ett kubernetes kluster helt frikopplat från Azure (förutsatt functionen inte använder en Azure specifik tjänst), så dessa kan även användas för att köra saker on-prem som ni inte vill eller kan köra i ett publikt moln eller en icke europeisk molntjänst.
Microsoft referensarkiteturförslag för Azure Functions
Slutligen kan ni ha intresse av att kika på Microsoft referensarkiteturförslag för Azure Functions så ni får en bredare uppfattning om vad man kan använda dem till och jämföra med det ni vet om logic apps, och även deras best pratices sida som tar upp viktiga saker att tänka på när man utvecklar Azure functions.
Robert Forsström's Blogg 