Why you probably shouldn't use Logic Apps for enterprise integrations

Introduction

Logic Apps are Azure's low-code approach to creating simple, repeatable workflows for executing various types of tasks. There are lots of use-cases where such workflows are a good fit-for-purpose but enterprise-scale integrations platform probably isn't one of those. I'll use my recent real-life experience from working with Logic Apps and a longer experience with more resilient and versatile integration patterns as a basis for my writing.

With that being said, you should take it with a grain of salt as it's only my humble opinion based on before mentioned experience.

But why would I say something like the title says? Nobody's doing it, right? Turns out, companies are doing it and here I'm bringing my opinion on why that maybe isn't the best idea.

Modern integration platforms should provide resiliency and scalability and offer a rich set of features such as efficient monitoring, queueing and state management. Implementing such features with Logic Apps seems counter-productive, although other Azure services could be used to help in some avail, e.g. Data Factory for orchestration.

Issues with using Logic Apps

Non-informative workflow failures

Ever experienced arbitrary failures with workflow integrations to other Azure resources which might require you to redeploy the whole solution? Or a built-in connector breaking as a result of an update?

I've faced these types of annoying issues even with a relatively short experience with Logic Apps. And I'm not saying these things wouldn't happen if you choose to use some other service or approach but these are just the kind of things that'll really ruin your day.

One special type of non-informative failure is when your Logic App hits memory and/or networking related boundaries with message/object sizes. There are some options for Standard Logic Apps which you can configure, but to my experience, they don't help much and there could still be that one boundary hidden from documentation that just makes you Logic App workflow drop the ball on it's execution.

Infrastructure-as-a-code support

Both Bicep and ARM Templates can be used to deploy and manage Logic Apps in Azure. However, I've faced some odd behavior and missing functionalities when trying to integrate Logic Apps workflows with other Azure resources.

Together with some missing key features, they may make implementing your solution a lot harder and/or unsafe.

• Unreachable Logic Apps webhook
  
  Logic Apps creates a webhook endpoint whenever adding a Http Trigger-type action to your workflow. That endpoint can then be utilized when integrating to other Azure/on-prem resources. I've noticed that the endpoint seems to work quite randomly. Creating a webhook connection to the Logic Apps endpoint can fail intermittenly due to errors in SSL handshake. There are workarounds for this but they require extra work which might hinder the effort of using Logic Apps in the first place if on of the main reasons for going with Logic Apps was to simplify and speed up development.
  
  

• Generic integration identity support
  
  For those connectors that don't support managed identities, it makes sense to use a generic integration identity for authentication. Generally, this account wouldn't have MFA enabled but the account still needs to login once to create the connection. There is currently no support for this in Logic Apps deployment framework and the login process needs to be executed manually for all instances/environments.
  
  

• Missing Logic App Standard API Management support
  
  Standard Logic Apps cannot be imported to API Management. If your APIs are hosted in API Management you need to create a proxy solution for your Standard Logic App or use Azure Functions as your API backend solution. On the other hand, Consumption Logic Apps can be imported to API Management.
  
  

Monitoring

Monitoring Logic Apps is far from straightforward. Consumption Logic Apps can't be connected to Application Insights instance at all. Logs are generated and can be viewed from the Logic Apps and sent to a Log Analytics workspace but creating a centralized log solution can become tricky. Application Insights connectivity exists for Standard Logic Apps only.

Furthermore, reading and interpreting Standard Logic Apps telemetry data from Application Insights requires quite the effort. Telemetry data is hidden in a way that building informative dashboards based on the data is a task for the at-least-intermediate level KQL enthusiasts.

If your solution requires more than just the bare minimum logging features, you just might want to use Azure Functions for that.

Limited authentication support for incoming requests

Logic Apps expose their endpoint URIs publicly. Although the endpoint is protected with a SAS token, anyone can access that URI unless the Logic App is hosted in App Service Environment(Standard) in an isolated network. Authentication can be performed with limited OAuth support by configuring the required claims with authentication policies, but you can only use a predefined set of basic claims for authorization.

More information on OAuth support: https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-securing-a-logic-app?tabs=azure-portal#enable-azure-active-directory-open-authentication-azure-ad-oauth.

If you need more authentication options and/or more fine-grained control over the authentication/authorization process, consider hosting the Logic App endpoint in API Management which supports additional authentication mechanisms such as Basic Authentication and Client Certificates.

Pricing

As with all other Azure consumption and pricing calculations and estimations, they all depend on the required capabilities and exact use case and more specifically data usage and the amount of network traffic.

With Standard Logic Apps compared to Functions, there is not much difference between hosting plan options and pricing.

More detailed information on Logic Apps billing: https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-pricing

The real difference comes with using the connectors. Consumption Logic Apps pricing is based on Logic App triggers and actions. For Standard Logic Apps, only actions apply for extra costs.

Additional pricing applies for each connector execution in a Logic App.

Using the above mentioned information it's easy to conclude that the higher the amount of connectors in a Logic App, the higher the costs. Also, with consumption-based Logic Apps, triggers generate extra costs.

So basically, if you have a consumption Logic App with a single connector and three million executions in a month compared to a Function App with consumption plan with the same amount of requests, the pricing is roughly as follows:

And this is just with a single standard connector.

Final words

Don't get me wrong, I really like the idea of no-code/low-code approach in general. In addition to the points mentioned earlier, there's just this overall feeling of not being quite there with all the mixed capabilities and available set of features between Consumption and Standard Logic Apps.

And as with all other Azure services, the decision on whether or not to use a certain service for your scenario is dependent on multiple factors such as the amount of transactions, available budget and team composition and experience.

I'd still use Logic Apps for simple and repeatable workflows such as importing/exporting files and sending notifications etc. but the idea of using Logic Apps as an enterprise integration platform is an idea you might want to revisit.