Why LogicApps Hybrid?
Azure Logic Apps have long been a powerful tool for building and deploying workflows, integrating applications, and automating tasks across a variety of environments. Organizations often face unique challenges when integrating applications and data across cloud and on-premises systems. The new Logic Apps hybrid model enables to operate in environments with limited cloud connectivity or specific local processing and network needs, addressing unique challenges such as data residency, compliance requirements, or low-latency demands.
The Logic Apps hybrid deployment model provides a solution by allowing organizations to:
- Host workflows on their own infrastructure (e.g. customer managed Kubernetes infrastructure), while still benefiting from the Logic Apps platform.
- Run workflows closer to where the data and the systems to be integrated reside, reducing latency.
- Use Azure Arc to extend Logic Apps to Kubernetes environments, offering flexibility to deploy workflows in virtually anywhere ( cloud, on-premises, edge).
- Provide a consistent management and governance experience across hybrid and multi-cloud environments (same control plane).
- Provide a more granular unit of scale by moving away from the app service plan model.
The following image provides a high-level overview of the Logic Apps hybrid architecture. Note that this is a partially connected setup, as your remote Kubernetes cluster must maintain an outbound connection to the Azure control plane to fetch configuration changes, receive new deployments, and propagate logs, billing information, and more.
Prepare the infrastructure
To get started with deploying Logic Apps in a hybrid model, you’ll need to prepare an arc-enabled Kubernetes environment. Below what you need to ensure your infrastructure is ready (You can find the full installation procedure here) :
- A Kubernetes cluster. We started with a brand new empty cluster, without any additional components.
- Make the AKS cluster arc-enabled (a set of components are created in the azure-arc namespace)
- Create a LogAnalytics workspace to access to the logs of the applications that are running in the arc-enabled cluster. The connection details for the workspace will be passed as input parameter to the next command.
- Install the container apps extension. The following pods will be created in the namespace passed to the “az k8s-extension create” command. In my case the Azure Container Apps runtime has been created in the “logicapps-aca-ns” namespace, the installation took approximately 35 minutes to complete.
- Create an arc location and a container app environment. These are arc artifacts, a sort of virtual twins to project a remote location and environment into the cloud model.
- Create a SQL Server. For this exercise I used Azure SQL ( “az sql server create” + “az sql db create”) but I could also opt for SQL Express on my laptop alongside a lightweight Kubernetes distribution like K3D. SQL is used to persist the state of our workflows, the run history details and more. After creating the SQL resources I enabled a private access to this database using a private IP address from the AKS virtual network leveraging a private endpoint (“az network private-endpoint create”, “az network private-dns link vnet create”. “az network private-endpoint dns-zone-group create”).
- Set up an SMB file share. To keep this exercise as simple as possible, I created a storage account with a file share named “intshare” and added a new folder called “firstsight” dedicated to the first logic app we are going to create once the infrastructure configuration is completed.
We can check the resources created so far in the Azure portal. Note that, the following image doesn’t include the VNET, private endpoint, DNS, etc., as I created them in a separate resource group.
Notes:
- As a first attempt, I tried using AKS Automatic (instead of a plain AKS cluster), but I couldn’t proceed with the Azure Container Apps extension installation because the ACA extension requires its own version of KEDA (see image). This issue deserves further investigation, as it could be a potential adoption blocker; the extension cannot be installed on clusters where applications rely on a different version of KEDA.
- For a more enterprise scenario where ingress and egress traffic passes through a firewall, additional configuration is needed to allow necessary ports, protocols, and URLs. Checkout the arc network requirements here.
Deploy a workflow
Now that our hybrid infrastructure is ready, let’s deploy a LogicApp and a workflow.
- Trigger the deployment by submitting an ARM template by using the tool you prefer (az cli, azure portal, …).
- The Azure Arc runtime discover the changes by polling the azure control plane.
- The Azure Container Apps runtime triggers the Kubernetes deployment and store the workflows in the SMB share
- As result of the Kubernetes deployment a new pod is created.
- The LogicApps pod contains the “logicapps-base” container that will be responsible to fetch the workflow from the SMB share and host it
To keep this exercise as simple as possible, we configured our first LogicApps hybrid using the Azure portal.
As a part of the ‘basic’ information it’s important to specify the ACA environment to be used which represents the K8S namespace where the Logic App pod will be created. While the Arc location technically represents a namespace, since only one ACA environment can be defined per location, we can view the ACA environment as equivalent (twin) to a Kubernetes namespace. As a second step we configured the connections to the external storages (SQL and SMB share) and as a final step we specify that we want to keep our logic apps private meaning we do not want to expose our workflows outside the Kubernetes cluster.
Once deployment is complete, the Arc magic happens, and our Logic App pod (woffo-portal–anjl87h-d58b9766d-5dscq) appears in the cluster. Need to adjust the pod configuration (such as scaling or resiliency)? Simply define the desired state in Azure, and the configuration will be automatically fetched and applied to the AKS cluster.
Note that, so far, we have created the Logic Apps but have not specified any workflows to execute.
- One option is to go to the Azure portal and use the workflow designer to submit our workflow; however, at the time of writing, this feature isn’t fully functional (as expected in a preview release, which comes with a set of well-known limitations).
- Another option is to use the Azure CLI to submit the ARM template with the workflow definition. I haven’t explored this approach yet or checked if the CLI has been updated to support Logic Apps hybrid mode..
- I chose the simplest approach by creating a subfolder in the SMB share, naming it after my workflow (e.g., warehouse-wf01), and uploading the workflow definition file (workflow.json).
Returning to the Azure Portal, if we select our previously created Logic App and navigate to the Workflows area, we can see our workflow up and ready to be invoked.
The workflow overview provides additional information, including the workflow status, URL, trigger type, workflow type, runtime version, and more.
Notes:
- The new approach to Logic Apps Hybrid differs significantly from what we experienced years ago. Not only it is now based on the ACA extension rather than the APPSVC extension, but it also eliminates the need to build a container to package workflows and related artifacts. This approach resembles the (now archived) DAPR Logic Apps extension project, where a single container image with the runtime is used for all Logic Apps, and workflows and custom artifacts are loaded via an external volume (dependency on the csi-driver-smb).
Trigger the workflow
When we created the Logic Apps, we specified the option to limit ingress traffic to the Container Apps environment, meaning our workflow won’t be reachable from outside the Kubernetes cluster.
Keeping this traffic private will make our CISO happy Let’s now get the internal workflow URL by taking the “Workflow URL” and and adding the ‘.internal’ segment as specified in the LogicApp’s application URL. In my case:
- Workflow URL : https://woffo-portal.la-env-0r6975brs6ymwgkgi.westeurope.k4apps.io:443/api/warehouse-wf01/…/…wP5KA
- Application URL : https://woffo-portal.internal.la-env-0r6975brs6ymwgkgi.westeurope.k4apps.io
- Resulting Internal Workflow URL : https://woffo-portal.internal.la-env-0r6975brs6ymwgkgi.westeurope.k4apps.io:443/api/warehouse-wf01/…/…wP5KA
As a final step, let’s connect to a POD and perform a first test call.
Great! Everything works as expected.
We can now go to the Azure Portal, select our Logic App, and view the run history along with detailed workflow run information. These details are stored in a SQL database (cloud, on-premises, or edge) and are retrieved by the Azure Portal through polling a public endpoint exposed by the Azure Container Apps extension.
Notes:
- Some functionalities, such as resubmitting (where the Azure Portal triggers a command to rerun the workflow in the connected remote location), are not yet operational—after all, it’s still in preview.
- While the semi-connected nature of Logic Apps Hybrid will mitigate any connection issues, it would be great to have the option to temporarily run in a fully disconnected mode, along with a local dashboard in the cluster to monitor the status of our workflows.
Conclusion
The introduction of Logic Apps Hybrid, now powered by Azure Arc and the Azure Container Apps extension, marks a significant step forward in enabling flexible, hybrid integration solutions for customers with requirements around latency, compliance, and data residency. Although some functionalities are still in preview and have limitations, this approach shows great promise for enterprises aiming to deploy and manage complex integration solutions across hybrid and multi-cloud environments.
As Logic Apps Hybrid evolves, it opens new possibilities for seamless integration, closer data proximity, and a unified management experience. We’re excited to see how this model will mature and expand, making hybrid workflows more accessible and manageable for everyone.
Subscribe to our RSS feed