Why Running Azure Logic Apps Anywhere is a Game Changer

This article was first published on Codit blog.

At Codit, we have been building integration solutions for well over 20 years. We started by using Microsoft BizTalk Server, which is a fully-fledged integration platform which you can run on-premises to integrate your business with your partners, external systems, and more.

As time flew by, we’ve seen Microsoft’s integration vision take shape in their cloud. They first released a public preview of Azure BizTalk Services, followed by Azure Logic Apps which gives customers a serverless workflow experience on which you can build cloud-native (integration) solutions.

Unfortunately, not everyone can rely on Microsoft Azure for numerous reasons, such as latency and on-premises requirements are just a few to highlight.

During //BUILD/ 2020, Azure Logic Apps team showed a demo allowing you to run Azure Logic Apps anywhere, thanks to it running on Azure Functions.

We are excited about the new capability to run Azure Logic Apps anywhere, that was announced to be in public preview today and believe this is a game-changer for Microsoft’s integration stack.

We have been actively participating in the private preview and want to share how it works, what it enables and where we believe it should go.

What is Azure Logic Apps Anywhere?

Azure Logic Apps is a fully managed service in Azure where you deploy your JSON workflow and they manage everything for you! However, you fully depend on Microsoft Azure as you cannot run it outside of their datacenters, not even on Azure Stack.

With Logic Apps anywhere, they have reworked the Logic Apps runtime and re-platformed it on top of the Azure Functions runtime allowing you to self-host your workflows. This means that like the Azure Functions runtime, you can practically run your workflows anywhere!

Does that mean we can run our Logic Apps fully isolated? No. You can build self-hosted workflows which can use a combination of built-in connectors, which will run inside your self-hosted runtime, or the cloud-connectors which we are familiar with.

In summary, here is an overview of what that looks like:

While the built-in connector offering is currently limited to things like Azure Event Hubs, Azure Service Bus, HTTP request, local Azure Function, scheduler, SQL Server and flow control we are hoping that this will expand in the future.

A unified integration strategy

As of today, you can build and run Azure Logic App workflows and either run them on the shared infrastructure or an integration service environment (ISE).

With an ISE, you get a fully dedicated workflow runtime which is fully isolated from other Azure customers.

This gives us a straight-forward approach for running our workflows in Azure:

But how about multi-cloud scenarios? On-premises solutions? Hybrid scenarios? Then you are out of luck.

We believe that therefore self-hosted Azure Logic Apps is a game-changer. We can author our workflows, package them as containers and ship them anywhere – be it on-premises, on Kubernetes, on the edge (such as ships), or on another cloud for multi-cloud/vendor lock-in scenarios; it is up to us to decide!

However, self-hosting workflows is not a trivial thing as you now have more responsibilities:

• Monitoring which integrates with Azure Monitor, but we will see support for Azure Arc in the future.
• Scaling for which you can use Kubernetes Event-driven Autoscaling but this heavily depends on your application composition to scale well.
• Security to ensure you are running the latest and most secure Azure Functions runtime and would love to see integration with Azure Security Center & Azure Policy to enforce best practices.
• …

Are you using Dapr? We’ll, then that’s a 2^nd  option to run your Logic App workflows outside of Azure by using Dapr Workflows which was announced last May. However, this is out-of-scope for this article but Your Azure Coach created a nice video about it.

For these reasons, we believe that the Azure Logic Apps runtime should be the recommended hosting option unless there is a good reason to host it yourself.

See it in action!

Talk is cheap, so we want you to see it in action!

We have an example scenario where we are providing an e-commerce platform allowing their customers to purchase products from the catalog and initiate shipments to their homes.

They are planning on going to the cloud but unfortunately depend on legacy systems, such as a SQL Server database, and decided to use a multi-phase migration.

As part of their application modernization, Sello wants to run cloud-native application on-premises to be ready when they migrate to the cloud. By packaging their apps as containers and run them on Kubernetes on-premises to connect to their legacy systems such as SQL Server.

Their landscape contains the following components:

• An Order service where customers can create an order
• This exposes a REST endpoint which is served by a .NET Core Web API. Every order request will check the warehouse service to see if the order is available and initiate a shipment
• A Warehouse service to manage the stock of products that are available
• Provides REST endpoint to verify stock of a product and update it once shipments are initiated. All stock information is stored in an on-premises SQL database.
• A Shipment service to initiate shipments for orders
• Provides a REST endpoint to accept new shipment requests which will be handled asynchronously

Interested in running it yourself? You can find it on GitHub – https://github.com/CoditEU/logic-apps-anywhere

We will further extend the application so that everything is running on Kubernetes and deployable through Helm charts, to show an end-to-end example of Logic Apps on Kubernetes!

Our early thinking

It is great to see that Azure PaaS services are aligning their offerings outside of Azure and provide a consistent experience for Azure Functions, Azure Logic Apps & Azure API Management. This leverages a consistent experience of the solutions we build, regardless of where they are running.

We wrote a blog post last year of our early thoughts about running API Management anywhere and why this is important for our customers.

Self-hosted Logic App workflows will be a productivity boost for developers since they can run their workflows locally without having to rely on Microsoft Azure. Next to that, it will greatly improve quality given it can be incorporated in CI/CD pipelines to verify changes before even deploying them.

Self-hosted Logic App workflows gives you a lot of new ways to host them, allowing you to cover a lot more scenarios. Containers will play a crucial role in this story and it is crucial to run them reliably on an orchestrator such as Kubernetes. But be careful, it gives you additional responsibilities as mentioned above. Choose your hosting option wisely and we recommend using Azure Logic Apps as a standard.

There is one big missing piece to the whole puzzle and that is reliable messaging outside of Azure. For semi-connected scenarios we can still rely on Azure Service Bus for our messaging but not for all scenarios. We will need to use an alternative message broker such as RabbitMQ or ActiveMQ if we want to run on-premises but that gives us more responsibilities as well.

However, it is still in an early phase and we would like to see some additional features.

We would love to see:

• More built-in connectors allowing us to integrate with on-premises solutions more easily such as FTP, SAP, Dynamics, and more.
• Integration accounts anywhere, allowing us to use those on-premises to reduce latency
• Custom connector support with a marketplace experience, allowing customers to use 3^rd party connectors in case Microsoft does not support them yet or use in-house only connectors
• Monitor our workflows in one central place by using Azure Arc, giving operational teams a single pane of glass
• Enforce secure workflows with Azure Security Center & Policy, so we can monitor vulnerable workflows, enforce using specific runtime versions and more.

Thanks for reading,

Tom