Differences between Azure Functions and Logic Apps

Azure functions

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 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, 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 API’s.

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 in a secure way. 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 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, that needs to be installed on premises.
        Deployment With new functions template in VS 2017, the user can create function as a .NET project with class attributes used to define functions behavior. It also support CI/CD through VSTS Build and Release definitions 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 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 time 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 number of 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 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 light-weight alternative of full-blown API Management, to add security on top of your HTTP triggered Functions. In order 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 time. 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.

Reference

Advertisements
Posted in Misc. 1 Comment »

One Response to “Differences between Azure Functions and Logic Apps”

  1. Microsoft Integration Weekly Update: Oct 2, 2017 | Hooking Stuffs Together Says:

    […] Differences between Azure Functions and Logic Apps by Usman Shaheen […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: