Logic Apps

Logic Apps vs Azure Functions – A Key Comparison of Differences

Azure functions logic logic logic

Logic Apps

Developer Experience Azure Functions code is written in JavaScript, C#, F#, Node.js, Python, PHP, Batch, Bash, and PowerShell. The code can be written in Azure Portal or as an Azure Function project in VS 2017 In Logic Apps, workflows are created with an easy-to-use visual designer, combined with a simple workflow definition language in the code view.
Connectivity Azure Functions have the concept of triggers, and input and output bindings. Most of these bindings connect your Azure Functions to other Azure services, such as Event Hubs, Storage, DocumentDb, etc. The HTTP binding is probably the most popular one, as it allows the creation of serverless APIs. Logic Apps connects to an enormous variety of cloud / on-premise applications, going from Azure and Microsoft services over SaaS applications and social media to LOB systems. Each connector comes with an API connection, that stores the required credentials securely. These API connections can be reused from within multiple Logic Apps
Exception Handling In Azure Functions, you have the typical try/catch options available. If you want to enable retries, you need to do the plumbing yourself. No resume / resubmit capabilities out of the box logic logic logic Logic Apps provides out-of-the-box functionality that allows you to configure automatic retries on every action. In case this doesn’t solve the problem, the workflow gets a failed status and can be resubmitted after human intervention
Networking When using Azure Functions within an App Service Plan, you have more convenient hybrid connectivity options that reside on the network level. App Service Plans offer support for many networking options like Hybrid Connections, VNET Integration, and App Service Environment. Azure Logic Apps can connect to on-premises resources via the On-Premises Data Gateway, which needs to be installed on-premises.
        Deployment With the new functions template in VS 2017, the user can create a function as a .NET project with class attributes used to define function behavior. It also supports CI/CD through VSTS Build and Releases definition logic Logic Apps also have built-in support for ARM (Azure Resource Manager) deployments, through for example Visual Studio Release Management.
Debugging Azure Functions can be easily developed and debugged on your local box or you can attach the debugger to a function deployed in Azure Logic Apps run only in the cloud, as it has a dependency on Microsoft-managed connectors. As a consequence, you cannot debug, test, or run Logic Apps locally. 
monitoring each  Each Azure Function comes with a Monitor tab, where you can see the execution history. There is also a live event stream that shows the almost real-time processing statistics in nice graphs. On top of that, there’s full integration with Application Insights, where you can take advantage of the powerful Analytics queries. In Logic Apps, you have a nice overview of the previous runs and their corresponding outcome. You can filter this history, based on a period and the resulting run status. The monitoring view of a workflow run is the same as the designer view, which makes it very intuitive. For each action, you can see the status and all inputs/outputs. With one button click, you can enable integration with OMS, where you can search on tracked properties.
Billing Azure Functions, you have two options qua pricing. You can opt for a fixed cost of an App Service Plan. In that option, you reserve compute power on which you can run Azure Functions and other App Services. The second option is completely serverless, with a consumption plan based on resource consumption (memory/s) and several executions. 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. If you want to benefit from the capabilities of the Integration Account, you should be aware that this comes with a fixed monthly bill.
Security Azure Functions has a similar concept of API keys as described in the logic Apps section. The API key can be shared for the whole Function App (host key) or you can create a specific one for your Function. If you run your Azure Function in an App Service Plan, you can leverage its codeless authentication functionality with Active Directory, Google, Facebook, etc. Azure Function Proxies can be a lightweight alternative to full-blown API Management, to add security on top of your HTTP-triggered Functions. To access a Logic App with the HTTP trigger, the client must include a Shared Access Signature in the URL. The signature is generated via a secret key that can be regenerated at all times. There is also the ability to restrict access, based on incoming IP addresses. To add more authorization logic, you can put Azure API Management in front of it.
[themeone_spacer height=”24px”]

Author

Hassan Askari