Organizing logic apps workflows with Logic Apps Standard
One of the common asks from customers, when requesting guidance for Logic Apps Standard is "How many workflows can I host in logic apps standard application"?
Coming from a Logic Apps Consumption paradigm, where developers simply organize logic apps in resource groups - deploying them individually using ARM template scripts - and use the Logic Apps Engine provided by the platform, this is a pertinent questions, as users would like to know how much value for money they can expect from the hosting service that they are subscribing to, and most important, how and when should they worry about scaling up or scaling out.
But that is not a straightforward question to answer, because there are many variables that would impact the answer. Some examples of those variables are:
- The complexity of the workflow
- Concurrent instances of the same logic app running
- Concurrent instances of other logic apps running
- Payload size
So, although guidance can be provided based on a very specific guideline, performance test needs to be applied for individual cases, before a definitive answer can be provided.
Logic Apps Standard and Workflow Standard (WS) App Service Plan
As Logic App Standard is implemented on top of the Azure Functions runtime, their hosting model is similar to Azure Functions model, requiring an app service plan to host that application. In the case of Logic Apps, this is a specialized app service plan, that comes in three different tiers:
|
Plan |
Configuration |
|
WS1 |
210 total ACU 3.5 GB memory Dv2-Series compute equivalent |
|
WS2 |
420 total ACU 7 GB memory Dv2-Series compute equivalent |
|
WS3 |
WS3 840 total ACU 14 GB memory Dv2-Series compute equivalent |
This is important to understand, as just as an Azure Function or Web App, a single WS App Service Plan can host multiple Logic App Standard apps, which means that you don't have to deploy all your logic apps workflows in a single Logic App Standard app, but instead break them down in groups that help you better manage the other aspects of the solution. This way you can take the most out of your App Service Plan, and future proof your applications, as they can be implemented in a way that allow them to scale individually. You can find the recommendation from the App Services team of how many apps should be added to an app service plan here.
Organizing logic apps workflows in multiple Logic Apps Standard apps
With that in mind, maybe a better way to think about how many logic apps workflows should I put in a single Logic App Standard app, a better question is how best can I organize my workflows with Logic Apps Standard? Rephrasing this question allows us to think about different scenarios where grouping logic apps can impact your business:
- Business process affinity
- End to end monitoring and support
- Security / Role Based Access Control / Network isolation
- Performance / Business criticality
- Geo-location / Geo-redundancy
Let’s explore those scenarios and think how grouping logic apps workflows in different Logic Apps Standard apps can help you improve various aspects of the development and maintenance lifecycle of your workflows.
Business process affinity
Grouping logic apps workflows that perform related or co-dependent business processes can help you to implement, test and deploy logic apps without impacting other processes, even when if they have the same underlying app service plan. The conceptual diagram below shows an example:
In the example above there are three Logic App Standard apps - Orders, Shipment Notification, Overnight Batches - each one with multiple logic app workflows that are used to fulfil a specific business process. All apps are being hosted by the same WS App Service Plan (Workflow Plan 1).
Organizing the logic apps this way, allows changes in the Orders Logic App Standard app to be implemented, tested, and deployed without having any impact on Shipment Notification or Overnight Batches.
It is important to notice that by being attached to same App Service Plan, those Logic Apps Standard apps will be affected by any scaling settings defined on that app service. This will be discussed in more details when talking about performance and business criticality.
End to end solution monitoring
Rarely, integration workflows live in isolation of a bigger solution, which means that is critical for monitoring and troubleshooting to have a picture of the end-to-end business processes, providing good observability to where a particular request is currently situated, in which step of the business process a particular request failed, from where the process can restart safely.
With Logic Apps Standard support for Application Insights, end to end monitoring, alerting and insights can be achieved, storing core metrics and relevant instrumentation within the same repository. But as Application Insights is attached to a Logic Apps Standard App instead of each individual workflow, mixing workflows that are relevant to that end-to-end process with other workflows can create noise, making it much harder to find the information required.
The diagram below shows an example where keeping logic apps workflows organized in different apps can help you to maintain your app insights segregated by area.
In the diagram above, creating an unified and clean view of the ordering business process is possible because Orders, Shipment Notification and Scheduled Tasks workflows are grouped into their own Logic Apps Standard apps, so applying different App Insights repositories to each workflow. This way, errors from the overnight batch process don’t appear in the ordering process App Insights – making alerting and troubleshoot activities much easier.
Security / Role Based Access Control (RBAC) / Network Isolation
Another good reason to break down logic app workflows into apps is to have more granular control about access to the workflows, associated run history, application configuration – including app settings - as RBAC is configured at the resource level- in this case a Logic Apps Standard app as opposed to each individual Logic Apps Consumption workflow.
Network integration, including VNET Integration and Private endpoints are also implemented at app level, so breaking down workflows into applications allow you to connect them to separate virtual networks and subnets, segregating them between publicly available interfaces, publicly available interface with outbound access to virtual networks, and isolated interfaces - where both inbound and outbound flows are contained to a virtual network boundary.
As the diagram above shows, by organizing logic apps workflows in different applications, you can select which applications will connect to a Virtual Network, and if any inbound interface will have public access, or be only available to resources within the virtual network – via private links.
Performance / Business Criticality
Having multiple Logic Apps Standard associated to a single WS App Service Plan can help you manage better your cost, but when one of the apps starts to request more CPU or memory from the host than the others, you can have issues where that app is driving the scale of the underlying App Service plan, affecting the performance of the other apps associated to the App Service Plan. In some other scenarios, you want to make sure that you have dedicated capacity for a particular set of business scenarios, as you can’t afford any kind of disruptions from noisy neighbors.
The solution for both cases is to make sure that those applications that have dedicate memory and CPU resources, hosting them dedicated App Service Plan with the appropriate sizing, and with the best scale-out configuration for bursting scenarios.
In the diagram below, you can see how the original setup of Orders, Shipment Notification and Overnight Batches can be rearranged to have Orders running on a dedicated App Service Plan.
This new setup could solve two scenarios:
- Orders having bursts in particular times of the year, which would be triggering a scale-out of the hosting plan, impacting the performance of shipment notification and overnight batches.
- Orders – which usually can have strict SLAs and should run 24/7 in a global market – having its performance impacted when other schedule services, like shipment notification and overnight batches are triggered.
In both scenarios, having a dedicated application that can be deployed and hosted in isolation, allows you the flexibility to rearrange the hosting plans and scaling configuration.
Geo-location / Geo-redundancy
Having logic apps as a resource available in most of the Azure regions across the globe allows customers to deploy their applications as close as possible to the consumers of the solution, improving application latency and availability. Organizing your worklog in smaller applications that covers more granular business processes, allow you to choose how those applications are deployes across Azure Regions, taking advantage of global traffic routers like Azure Traffic Manager and Azure Front Door, which can identify the best region to route traffic to, based on regional affinity, latency and/or utilization.
The diagram below shows an example where scheduled workflows, like shipment notification and overnight batches are deployed in a single region while Orders – which requires better latency and availability to support clients across the globe - is deployed in multiple Azure regions.
Having multiple regions available can also protect critical processes from regional failures in the Azure infrastructure, as sometimes dependent services might be down, which would force you to move the traffic to a secondary region, for business continuity.
So, using the diagram above as a reference - as part of a Business Continuity Plan (BCP), all workflows currently deployed in Australia East can be deployed to Australia Southeast on demand, in case of a regional failure in Australia East region would affect their Recovery Time Objectives (RTO). Alternatively, if an on-demand deployment wouldn’t be sufficient to cover your RTO, you can have the workflows deployed on the secondary region but disabled, being enabled as part of your BCP.
Summary
Maximizing the utilization of your App Service Plan can be a way to improve the cost of your Logic Apps Standard implementation but shouldn’t be the only consideration when architecting solutions. Breaking down your workflows in smaller groups that help you better manage some other aspect of your implementation, like observability, security, performance, and availability should also be taken in consideration.
Ideally, those aspects should be taken in consideration first – once the right set of workflows is defined, the application can then be stressed tested, to find the right compute size for your App Service Plan, and the right scaling configuration for your peak periods.