We were asked by a client about how to choose between Microsoft’s Azure Logic Apps or Azure Functions for an integration project. This post is the response that we gave to our client and will help you compare and choose between the two. How do you choose which one is right for your business objectives, or should you use both?
Walkerscott has extensive experience both implementing and operating these solutions, and we can help you make the right choice when deciding on the best technology to benefit your organisation. We have also developed Klevr Integration Hub – an Azure integration accelerator based on Microsoft’s Integration best practices and our experience implementing hundreds of business-critical integrations. If you want to talk further, get in touch!
Microsoft’s Azure Logic Apps vs Azure Functions Comparison Table
| Solution | Azure Logic Apps | Azure Functions |
| Summary | Azure Logic Apps is a cloud service that helps you schedule, automate, and orchestrate tasks, business processes, and workflows when you need to integrate apps, data, systems, and services across enterprises or organizations. |
Azure Functions is a serverless compute service that lets you run event-triggered code without having to explicitly provision or manage infrastructure. You can build Azure Functions in various languages like C#, F#, Node.js & Typescript, Python, Java and Powershell. |
| Development | Logic Apps have a “Designer-First” (declarative) experience for the user by providing a visual workflow designer accessed via the Azure Portal. Users get access to the full source code JSON template that is automatically created by visual designer and can also author Logic Apps via Visual Studio with a designer plugin or by coding. | Azure Functions have a “Code-First” (imperative) for user experience and are primarily authored via Visual Studio or another IDE. There is lightweight but limited configuration available within the Azure Portal. Unlike Logic Apps there is no visual workflow designer available. |
| Execution Context | Run only in Azure |
Can run locally, on any self managed server, in containers or in Azure (serverless) |
| Connectivity & Actions |
Logic Apps have a large collection of connectors to Azure Services, SaaS applications (Microsoft and others), FTP and Enterprise Integration Pack for B2B scenarios; along with the ability to build custom connectors if one isn’t available. Each pre-existing connector has a range of ready-made actions that can use used and configured via the visual designer or in code. |
Azure Functions have about a dozen built-in binding types (mainly for other Azure services). If there isn’t an existing binding, you will need to write custom code to create new bindings. Azure Functions do not have connectors, yet rely on triggers and input and output bindings – like Storage, Event Hubs, Service Bus and Cosmos DB. Bindings in Azure Functions provide a way to connect to data with code declaratively. The list of bindings is very limited compared to Logic Apps. |
| Scaling and Pricing Model |
Logic Apps provide specific auto-scale capabilities, i.e. when your load increases the Logic App can scale with it to a certain point and will scale depending on the connector(s) you use. Logic Apps has a pure pay-per-usage billing model. You pay for each action that gets executed. It’s important to be aware that you also need to pay for polling triggers, which can be a hidden cost. |
Depending on the chosen plan, Azure Functions will automatically scale based on the number of incoming events. With Azure Functions, you have 3 pricing options. You can opt for a fixed cost of an App Service Plan, which gives you dedicated resources and some other characteristics like unlimited execution time per run. The second option is completely serverless, with the consumption plan based on resources consumed and number of executions. The third option is Functions Premium, which is a hybrid of both the App Service Plan and Consumption Plan. |
| Deployment | There are many ways to manage and deploy Logic Apps. They can be created and updated directly in the Azure Portal (which will automatically create a JSON template). The JSON template can also be deployed via Azure DevOps and Visual Studio. | As Azure Functions are code-first, the only options for deployment are Visual Studio, Azure DevOps or FTP. Klevr Integration Hub leverages Azure DevOps too, so there is no operational lock-in to a proprietary integration technology framework. |
| Security |
Every connector comes with its own security. For example, the Dynamics 365 connector requires a Dynamics user account. Logic Apps can also be secured with IP whitelisting and VNet Integration via an Integration Service Environment. Furthermore, you can secure Logic Apps by placing Azure API Management in front of them. |
Azure Functions are secured with Authorization keys that are automatically generated, and you can also create custom keys. As with Logic Apps you can secure Functions with IP whitelisting and VNet Integration. You can also place Azure API Management in front of them or use the lightweight Azure Functions Proxies functionality. Additional security/isolation can be achieved if Functions are deployed in containers or a self-managed compute environment. |
| Exception Handling | Logic Apps provides out-of-the-box functionality with retries, scopes, and run after configurations. In case this doesn’t solve the problem, the workflow gets a failed status and can easily be resubmitted after review in the Azure Portal. | As with other Code-First solutions, in Azure Functions you are required to build your own exception handling. For example, if you want to enable retries (and you should if you are working with any other cloud services), you need to create the logic yourself, for example by introducing Polly (which we use and recommend in C# Functions). There are no retry, resume or resubmit capabilities, unless you develop them yourself. |
| Monitoring | Logic Apps are much easier for non-technical users to manage as each run can be monitored within the Azure portal including stopping, starting, cancelling and re-processing. Comprehensive reporting can be achieved via Azure Monitor logs. | Functions can be managed via a simple monitor tab in the Azure Portal or comprehensively monitored down to code level via Application Insights. Functions are not easy to manage/monitor for non-technical users. |
| Management | Azure portal, REST API, PowerShell, Visual Studio |
Azure Portal, REST API, Visual Studio |
Summary
Based on the comparison above, you’ll notice that a lot of factors are involved when deciding between the two technologies. Some questions to help guide you to the right technology might include:
- Understand what skillsets you have internally to build, operate and support the solution.
- Determine your connectivity requirements – do you want to write it yourself or you want to leverage out-of-the-box connectors/bindings?
- Do you have very complex business and/or data transformation logic?
Walkerscott’s Recommendation:
Use both!
We generally recommend using Azure Logic Apps to manage the overall scheduling and orchestration of tasks and workflows and to extend these with point solutions based on Azure Functions for more complex business and/or data transformation logic.
This gives business users an easy to view and manage monitoring console based on Logic Apps visual workflow designer and the full power of an Azure Functions code-based solution for more complex challenges, but only when required.
Talk to us about Klevr Integration Hub!
We find clients can reduce their integration build time/costs by up to 75% leveraging Klevr compared with developing integration “by hand” using Azure iPaaS services.