What is Microsoft Azure Logic Apps Standard?
Table of Contents
What is the Azure Logic Apps Standard?
Azure Logic Apps Standard is a cloud-based platform for automating logic app workflows that connect your apps, data, services, and systems. You can easily build highly scalable integration solutions for your corporate and business-to-business (B2B) situations with this platform. You may use either the Logic App (Consumption) resource type or the Logic Apps Standard resource type to construct a logic app. The Consumption resource type is for multi-tenant Azure Logic Apps or integration services, whereas the Standard resource type is for single-tenant Azure Logic Apps.
Review this article before deciding which resource type to utilize to see how the different resource types and service contexts compare. Based on your scenario’s demands, solution requirements, and the environment where you want to deploy, host, and operate your workflows, you may then select which kind is ideal to utilize.
Azure Logic Apps Environments and Resource Types
You pick the Logic App resource type to construct logic app workflows depending on your scenario, solution requirements, desired capabilities, and the environment in which you want to conduct your processes.
The differences between the Logic Apps Standard and the Logic App (Consumption) resource types are summarised in the table below. For installing, hosting, and operating your logic app processes, you’ll also understand how the single-tenant environment compares to the multi-tenant and integration service environment (ISE).
| Resource type | Benefits | Resource sharing and usage | Pricing and billing model | Limits management |
|---|---|---|---|---|
| Logic App (Consumption) Host environment: Multi-tenant Azure Logic Apps | – Easiest to get started – Pay-for-what-you-use – Fully managed | A single logic app can have only one workflow. Logic apps created by customers across multiple tenants share the same processing (compute), storage, network, and so on. | Consumption (pay-per-execution) | Azure Logic Apps manages the default values for these limits, but you can change some of these values, if that option exists for a specific limit. |
| Logic App (Consumption) Host environment: | – Enterprise scale for large workloads – 20+ ISE-specific connectors that connect directly to virtual networks – Predictable pricing with included usage and customer-controlled scaling – Data stays in the same region where you deploy the ISE. | A single logic app can have only one workflow. Logic apps in the same environment share the same processing (compute), storage, network, and so on. | ISE (fixed) | Azure Logic Apps manages the default values for these limits, but you can change some of these values, if that option exists for a specific limit. |
| Logic Apps Standard Host environment: | – Run using the single-tenant Azure Logic Apps runtime. Deployment slots are currently not supported. – More built-in connectors for higher throughput and lower costs at scale – More control and fine-tuning capability around runtime and performance settings – Integrated support for virtual networks and private endpoints. – Create your own built-in connectors. – Data stays in the same region where you deploy your logic apps. | A single logic app can have multiple stateful and stateless workflows. Workflows in a single logic app and tenant share the same processing (compute), storage, network, and so on. | Standard, based on a hosting plan with a selected pricing tier. If you run stateful workflows, which use external storage, the Azure Logic Apps runtime makes storage transactions that follow Azure Storage pricing. | You can change the default values for many limits, based on your scenario’s needs. Important: Some limits have hard upper maximums. In Visual Studio Code, the changes you make to the default limit values in your logic app project configuration files won’t appear in the designer experience. For more information, see Edit app and environment settings for logic apps in single-tenant Azure Logic Apps. |
| Logic Apps Standard Host environment: | Same capabilities as single-tenant plus the following benefits: – Fully isolate your logic apps. – Create and run more logic apps than in single-tenant Azure Logic Apps. – Pay only for the ASE App Service plan, no matter the number of logic apps that you create and run. – Can enable autoscaling or manually scale with more virtual machine instances or a different App Service plan. – Data stays in the same region where you deploy your logic apps. – Inherit the network setup from the selected ASEv3. For example, when deployed to an internal ASE, workflows can access the resources in a virtual network associated with the ASE and have internal access points. Note: If accessed from outside an internal ASE, run histories for workflows in that ASE can’t access action inputs and outputs. | A single logic app can have multiple stateful and stateless workflows. Workflows in a single logic app and tenant share the same processing (compute), storage, network, and so on. | App Service plan | You can change the default values for many limits, based on your scenario’s needs. Important: Some limits have hard upper maximums. In Visual Studio Code, the changes you make to the default limit values in your logic app project configuration files won’t appear in the designer experience. For more information, see Edit app and environment settings for logic apps in single-tenant Azure Logic Apps. |
Logic Apps Standard resource
The revised single-tenant Azure Logic Apps runtime powers the Logic Apps Standard resource type. This runtime is hosted as an extension on the Azure Functions runtime and leverages the Azure Functions extensibility paradigm. This approach gives your logic app operations additional portability, flexibility, and performance, as well as other features and advantages inherited from the Azure Functions platform and Azure App Service ecosystem. In Azure App Service Environment v3, for example, you may design, deploy, and execute single-tenant based logic apps and associated processes.
Similar to how an Azure function app may contain several functions, the Standard resource type offers a resource structure that can host numerous workflows. Due to their closeness, processes in the same logic app and tenant share computing and processing resources via a 1-to-many mapping, resulting in greater performance. This varies from the Logic App (Consumption) resource, which has a 1-to-1 mapping between a logic app resource and a workflow.
Azure Logic Apps Flexibility and Portability
You may deploy and operate your workflows in different settings, such as Azure App Service Environment v3 when you develop logic applications using the Logic Apps Standard resource type. You can design, build, and execute your processes in your development environment without needing to deploy to Azure if you use Visual Studio Code with the Azure Logic Apps (Standard) extension. Create single-tenant-based logic applications using Azure Arc-enabled Logic Apps if your circumstance necessitates containers. Review What are Azure Arc-supported Logic Apps for additional details.
When opposed to the multi-tenant paradigm, which requires you to develop against an existing operational Azure resource, these features provide significant enhancements and benefits. Additionally, the multi-tenant strategy for automating Logic App (Consumption) resource deployment is entirely built on Azure Resource Manager templates (ARM templates), which integrate and manage both app and infrastructure resource provisioning.
Because you can isolate app deployment from infrastructure deployment with the Logic Apps Standard resource type, deployment becomes easier. As part of your logic app, you may include the single-tenant Azure Logic Apps runtime and workflows. Generic steps or tasks may be used to construct, combine, and compress your logic app resources into deployable artifacts. You may still utilize ARM templates to supply those resources independently from other processes and pipelines that you employ for those purposes when deploying your infrastructure.
Copy the artifacts to the host environment and then start your apps to execute your processes to deploy your app. Alternatively, you may utilize your existing tools and procedures to incorporate your artifacts into deployment pipelines. That way, regardless of the technology stack you choose for development, you may deploy using your preferred tools.
You can focus on app development without worrying about infrastructure deployment if you use standard build and deploy settings. As a result, you get a more generic project model with many of the same or similar deployment options as you would for a generic app. You also get a more uniform experience when it comes to designing deployment pipelines for your app projects and running the necessary tests and validations before publishing them to production.
Azure Logic Apps Performance
You can construct and run several workflows in the same logic app and tenant using the Logic Apps Standard resource type. Because of the 1-to-many mapping, these workflows can share resources including computation, processing, storage, and network, resulting in greater performance.
By making the more popular managed connectors available as built-in operations, the Logic Apps Standard resource type and single-tenant Azure Logic Apps runtime deliver another substantial benefit. Built-in operations for Azure Service Bus, Azure Event Hubs, SQL, and other services are available. In the meantime, managed connector versions are still accessible and functional.
You create connections called built-in connections or service provider connections when you utilize the new built-in operations. API connections are the managed connection’s counterparts, and they’re produced and run separately as Azure resources that you must then deploy using ARM templates. Built-in operations and their connections execute on the same machine as your processes. Both are hosted on the Azure Logic Apps runtime, which is single-tenant. As a result of their proximity to your processes, built-in operations and their linkages deliver superior performance. Because the service provider connections are packed into the same build artifact, this solution works well with deployment pipelines.
Azure Logic Apps Data residency
Logic app resources built using the Logic Apps Standard resource type are hosted in single-tenant Azure Logic Apps, which means that data in your logic app processes stays in the same region where you develop and deploy their parent resources.
Azure Logic Apps Create, build, and deploy options
Single-tenant environment
| Option | Resources and tools | More information |
|---|---|---|
| Azure portal | Logic Apps Standard resource type | Create integration workflows for single-tenant Logic Apps – Azure portal |
| Visual Studio Code | Azure Logic Apps Standard extension | Create integration workflows for single-tenant Logic Apps – Visual Studio Code |
| Azure CLI | Logic Apps Azure CLI extension | Not yet available |
Multi-tenant environment
| Option | Resources and tools | More information |
|---|---|---|
| Azure portal | Logic App (Consumption) resource type | Quickstart: Create integration workflows in multi-tenant Azure Logic Apps – Azure portal |
| Visual Studio Code | Azure Logic Apps (Consumption) extension | Quickstart: Create integration workflows in multi-tenant Azure Logic Apps – Visual Studio Code |
| Azure CLI | Logic Apps Azure CLI extension | – Quickstart: Create and manage integration workflows in multi-tenant Azure Logic Apps – Azure CLI – az logic |
| Azure Resource Manager | Create a logic app ARM template | Quickstart: Create and deploy integration workflows in multi-tenant Azure Logic Apps – ARM template |
| Azure PowerShell | Az.LogicApp module | Get started with Azure PowerShell |
| Azure REST API | Azure Logic Apps REST API | Get started with Azure REST API reference |
Integration service environment
| Option | Resources and tools | More information |
|---|---|---|
| Azure portal | Logic App (Consumption) resource type with an existing ISE resource | Same as Quickstart: Create integration workflows in multi-tenant Azure Logic Apps – Azure portal, but select an ISE, not a multi-tenant region. |
You can identify and access all of your deployed logic apps under your Azure subscription, even if your development experiences change depending on whether you generate Consumption or Standard logic app resources.
The Logic apps page in the Azure portal, for example, lists both Consumption and Standard logic app resource categories. Deployed logic applications display in Visual Studio Code under your Azure subscription, but they are organized by the extension you used, specifically Azure: Logic Apps (Consumption) and Azure: Logic Apps (Production) (Standard).
Azure Logic Apps Standard Stateful and stateless workflows
Stateful
When you need to keep, evaluate, or refer to data from prior events, create a stateful process. These workflows save and transfer all of the inputs and outputs for each action, as well as their states, to external storage, allowing for post-run analysis of the details and history. If there are disruptions, stateful workflows give excellent resiliency. You can recreate interrupted runs from the preserved state and repeat the workflows to completion after services and systems have been restored. Stateful workflows can run for significantly longer periods of time than stateless processes.
Stateful workflows in Azure Logic Apps, both multi-tenant and single-tenant, run asynchronously by default. The typical asynchronous operation pattern is followed by all HTTP-based actions. This pattern specifies that the receiver delivers a “202 ACCEPTED” answer immediately after an HTTP action calls or submits a request to an endpoint, service, system, or API. This value indicates that the request was accepted but that the receiver is still processing it. The caller can use the location header to provide the URI and the refresh ID to poll or verify the status of the asynchronous request until the receiver ends processing and delivers a “200 OK” success response or another non-202 answer. The caller, on the other hand, is not required to wait for the request to complete processing before proceeding to the next step. See Asynchronous microservice integration enforces microservice autonomy for additional details.
Stateless
When you don’t need to maintain, evaluate, or refer to data from prior events in external storage for subsequent review, create a stateless workflow. These workflows save all of the inputs and outputs for each operation, as well as their states, in memory rather than on disc. Because the run information and history aren’t kept in external storage, stateless workflows feature shorter runs (usually less than 5 minutes), faster performance (quicker reaction times), higher throughput, and lower running costs. Interrupted runs are not automatically restored if there are outages, thus the caller must manually resubmit interrupted processes.
Stateless workflows do not use the normal asynchronous operation pattern used by stateful workflows because they only run synchronously. All HTTP-based activities that return a “202 ACCEPTED” response, on the other hand, advance to the next step in the workflow execution. A stateless workflow will not poll the supplied URI to check the status if the answer includes a location header. Instead, utilize a stateful workflow to follow the conventional asynchronous operation paradigm.
You can activate run history for a stateless workflow, which has an impact on speed, for simpler debugging, and then disable run history when you’re done. Create single-tenant based processes in Visual Studio Code or Create single-tenant based workflows on the Azure portal for further information.
Current Limitation, Unavailabilities, Not Supported
These capabilities have changed for the Logic Apps Standard resource, or they are currently limited, unavailable, or unsupported:
Triggers and actions: In Azure Logic Apps, built-in triggers and actions run natively, while managed connectors are hosted and executed in Azure. Sliding Window, Batch, Azure App Services, and Azure API Management are among the built-in triggers and actions that aren’t available. Use the built-in Recurrence, Request, HTTP, HTTP Webhook, Event Hubs, or Service Bus triggers to initiate a stateful or stateless workflow. Built-in triggers and actions are found under the Built-in tab in the designer.
Except for the unavailable activities indicated below, managed connector triggers and actions are displayed under the Azure tab for stateful workflows. When selecting a trigger for stateless workflows, the Azure tab does not display. Only managed connector actions, not triggers, are available for selection. Despite the fact that stateless workflows can use Azure-hosted managed connectors, the designer doesn’t offer any managed connector triggers for you to add.
Webhook-based triggers and actions require additional setup to run locally in Visual Studio Code. Create single-tenant-based workflows in Visual Studio Code for more information.
Clone Logic App: The extremely useful duplicate Logic App button has vanished.
Logic Apps Versions: Versions allow you to revert to a previous deployment. But in the Logic Apps Standard resource type is presently unavailable this feature and Deployment slots will be available soon, with the opportunity to roll back to the previous version.
Breakpoint debugging in Visual Studio Code: Breakpoints can be added and used within the workflow. Breakpoints are currently only supported for actions, not triggers, in a JSON file for a workflow.
Trigger history and run history: Trigger history and run history in the Azure portal appear at the workflow level, not the logic app level, for the Logic Apps Standard resource type.
Zoom control: The zoom control is currently unavailable to the designer.
Azure API Management: The Logic Apps Standard resource type is presently unavailable for import into Azure API Management. The Logic App (Consumption) resource type, on the other hand, can be imported.
Summary
That concludes this post, which provided an overview of how we may approach creating the solution as well as some of the moving pieces we must consider in order to create, deploy, and test the apps.
We’ve converted business needs into infrastructure and made certain technical decisions that will allow us to develop and deploy, and we’re now ready to begin the implementation, which we’ll discuss next. Keep an eye out for the follow-up articles on these themes.
- Part 2 – Logic Apps Standard Vs Consumption
- Part 3 – Azure Standard Logic Apps Pricing
- Part 4 – Azure Standard Logic Apps Connectors
- Part 5 – Create single-tenant based workflows in the Azure portal
- Part 6 – Create single-tenant based workflows in Visual Studio Code
- Part 7 – Azure Standard Logic Apps ARM Template
- Part 8 – Azure Logic Apps Standard Deployment
Finally, we’ll create the demo application and open source it so you can use it with your own Azure subscriptions.