An overview of Azure Logic App

Intro

As the world of IT evolves constantly, systems are getting more complex day by day. The need to synthesize and coordinate actions across multiple systems and services, schedule, automate processes and orchestrate tasks is a problem that a lot of companies face daily. There are several tools to help with this kind of problems, called Business Process Modeling (BPM) tools. BPM tools are used widely in our industry and can be very useful if used properly.

Logic App is a cloud service provided by Microsoft Azure that can help manage and model complex processes. It's especially helpful when your infrastructure is in Azure where it integrates perfectly with the majority of Azure services.

Use cases

Just to give a better overview of why you should use such a tool, here is a list of some common problems that Logic App can help with:

• Orchestrate multiple APIs
• Sequence batch processing jobs
• Send messages from automated workflows
• Publish events from serverless workflows
• Coordinate tasks in microservices and serverless applications
• Coordinate extract, transform and load (ETL) jobs

Features

Logic App is a mature tool with a lot of features supported by Microsoft. I will mention the most important features from my perspective that I find most interesting.

• Serverless: Pretty self-exploratory. Having your workflow running in a serverless environment is a big win.
• 200+ enterprise connectors: Logic App support connectors for both Azure and third-party APIs. Connectors can be build-in tasks that can connect to OneDrive, Azure Data Factory, Azure Event Grid, SAP, Adobe tools etc.
• In-built monitoring: By default Logic App provides history for runs and triggers, and performance. It also provides the option to set up alerts for workflow failures.
• Retry policy: Certain tasks like HTTP, OneDrive tasks, Azure Data Factory support a retry policy where you can configure how many and how often a retry should occur.
• Parallel running: Similarly to retry policy, some tasks do support parallel running like loops and parallel branches, where you can speed up your workflow execution by parallelizing the steam of work. Be aware that the tasks should not be dependent on each other because otherwise, you will probably have issues.
• Integrated Service Environment (ISE): ISE provides the possibility to access resources inside Azure virtual networks. This is particularly useful when your infrastructure is located in your organization's private network. You can find more to the official documentation here.
• Pay only for what you use (pricing model)

Drawbacks

Using Logic Apps for several applications in the last 6 months I can lay down some drawbacks that need to be considered before using Logic Apps.

• Hard to maintain: There is no git integration! This is something that I noticed from day one and still hurts me after 6 months. There is a workaround where you can extract the ARM template from the portal and store that to a repository. The problem with that approach is that there is no connection between the repository and the workflow living in the portal so there is no easy way to change the flow and integrate that into the code. > An alternative is to use the official plugin for Visual Studio, but I wouldn't recommend it since it's buggy.

• Hard to test: Testing workflows is quite difficult in general unless the tool provides a built-in solution to that issue. The only way you can test your workflow is with E2E tests on the visible side effects of the system. Logic Apps have a feature for testing the workflow using mock data and static results but it's still in preview and I don't think it's good enough yet.

• Limited Actions & Triggers: Although there is 200+ build-in connectors you might find that this is not enough. There is a way to build your custom connectors but I don't think it's straight forward and it could be easier.

• Ocassional UI bugs: Using the portal for the last few months now I identified some bugs regarding the dynamic content in the tasks which can be annoying but nothing huge, to be honest.

• Limited monitoring: Unfortunately the default monitoring of Logic App is not enough. It's really difficult to track down specific pipeline run in case of failure. This drawback can be disregarded by using a log analytics workspace.

Recommendations after 6 months of usage

Testing

Since testing is hard by default, I would definitely recommend using a testing environment. At a minimum, you should have a test logic app and a production one. Developing should be done to the test environment and if everything works as expected then the ARM template should be used to push to production using a pipeline.

Maintanability

I strongly believe that having a way to integrate with git is a must. ARM templates is a good way of doing it, so I suggest that you should have a release pipeline to deploy the ARM template of the workflow. By integrating your workflow code to git you can revision any changes, enforce code reviews and have consistency between environments.

To build such a release pipeline you can use Azure DevOps Release Pipelines configured with an ARM template Deployment.

Observability

One of the best perks of using a Logic App is that it integrates great with log analytics. You can get better debugging information about your logic apps during runtime, richer metrics, and track information about runtime data and events. Moreover, you can configure your logic app to track custom properties and store those in the logs. I would recommend to set-up a log analytics workspace when you build a Logic App since the build-in monitoring will not be probably enough. Having those logs will also give you the flexibility to create custom dashboards if needed.

Consistency

Maintaining two environments can be difficult. One way to tackle that is by restricting modifications in the production environment via the portal. This restriction will enforce discipline and avoid inconsistency between those two environments, so any change to production can be done only with code and a release pipeline. Ideally, you should have a single ARM template file for both environments and two-parameter files corresponding to each environment. This will minimize the chance of a bug.

Where not to use it.

Logic App should be mainly used for orchestrating workflows. ** It's important to avoid adding domain logic to the workflow**. You have to be conscious of when to use and why you are using such a tool as it can increase complexity if used wrongly (like any other tool). I wanted to highlight that because I've fallen into that trap where I used that tool for all kind of problems where it did not quite fit and made my life more difficult instead of easing it. My tips are: do not add domain logic to the workflow & follow the KISS principle.

Other Alternatives

This list can be huge since there are plenty of workflow tools so I will only mention some of them:

• Power Automate: An almost identical alternative to Logic App from Microsoft Office 365. I would recommend using Logic App instead of Power Automate since it has a lot of limitations regarding action limits.
• AWS Step functions : Step function is a great alternative and I would recommend it especially if your infrastructure is in AWS. AWS has templates for a lot of common use cases that can be useful to start with.
• Google Cloud Workflows.

Conculsion

Overall, Logic App has its drawbacks & its benefits like any other thing in life. Working with a tool like that for the last 6 months taught me a lot and extended my arsenal of choices in future problems since I haven't used a BPM tool before. I want to highlight that this tool is not perfect for every use case since it can be a huge tech debt because testing and maintainability can be tricky. On the other hand, the tool can be great for automating and orchestrating tasks with a really small learning effort and with a nice UI.