Tags :  

Understanding Azure Logic Apps Resource Types

Last updated on: May 31, 2021

In recent years, businesses innovate and migrate at a faster pace by using Microsoft Azure cloud-native technologies. Azure Integration Services, an industry leading Integration Platform as a Service (iPaas) provides multiple offerings like Logic Apps, Service Bus, API Management, Event Grid, Azure Functions & Data Factory to meet application integration scenarios.

Azure Logic Apps gaining good interest with more than 40,000 customers using it. It provides capabilities to create and run automated workflows and orchestrate business processes to connect hundreds of services in the cloud and on-premises.

In 2020, Microsoft Azure announced new Logic Apps in the preview that is different from the existing Consumption resource type with a different set of capabilities.

At the Microsoft Build 2021, a lot of new updates related to Logic Apps were announced:

  1. General Availability of Logic Apps (Standard) resource type
  2. It is a single tenant offering with a modern cloud-scale workflow engine supporting stateful and stateless workflows.

  1. Run Logic Apps anywhere
  2. Logic Apps (Standard) comes with a new portable runtime that provides flexibility to host and run-on Azure Functions, Azure App Service, Kubernetes, Docker, and any cloud.
    Now that Logic Apps is built on same containerized runtime as Azure Functions, it has got enterprise capabilities like private endpoints, simpler and more cost effective VNET access, deployment slots etc.

  1. Hosting options aligning with Azure Functions and App Service
  2. Enables creating Workflows and Functions that interoperate and extend each other’s capabilities in a more seamless way.

  1. Azure Arc enabled Logic Apps (Public Preview)
  2. This offering provides a centralized single pane-of-glass management platform from Azure Portal to control infrastructure and resources deployed in Azure, non-Azure, multiple clouds like AWS and Google, on premises, and edge environments.

    Not only for Logic Apps but this capability is also extended for the Azure Application Services i.e. Azure App Service, Azure Functions, Azure Logic Apps, Azure API Management, Azure Event Grid to run on Kubernetes and anywhere.

    Azure Arc enabled Logic Apps
  1. A new Visual Studio Code extension (Public Preview)
  2. Enables local development, easy debugging, and testing on local machine, set breakpoints, examine variables values during runtime.

    This helps to build and run workflows in development environment without having to deploy to Azure.

    Based on the requirement Logic Apps can be containerized and deployed as containers.

    new Visual Studio Code extension
  1. Environment variables
  2. Workflows can be parameterized in Logic Apps Standard while development so that deployments can be automated, and environment-specific values can be set in Application Settings making the pipelines in DevOps simple.

    Support to Azure DevOps pipelines and GitHub Actions, automated deployments and use CI/CD practices.

    Unlike in Consumption resource type, workflow settings, and parameters setup while design time are deprecated, application settings provide better security and DevOps experience.

    Azure Logic Apps
  1. Logic Apps designer is redefined
  2. Helps to design most complex business workflow, orchestration, and automation problems.

    The new layout engine making complex workflows render faster than ever.

    Step configurations are moved out of the cards into a new panel design for simpler and faster authoring.

    Logic Apps Consumption

    Let us now understand the differences between the existing Consumption and newly released Standard resource type:

Logic Apps (Consumption)

  1. Runs on Multi-Tenant environment or Dedicated Integration Service Environment (ISE) within Microsoft Azure.
  2. This is a Pay-for-what-you-use pricing model.
  3. Logic Apps created by different customers in multi-tenant environment or created in same ISE will share same processing (compute), storage, network, and so on.
  4. A single Logic App can have only one workflow.
  5. Trigger and Run histories are available at Logic App level as there is only one workflow.
  6. The long-running and stateful processes for workflows are inherently available in Logic Apps.
  7. Some of the limits could be changed if the option exists for that metric.
  8. Can be imported to Azure API Management.
  9. Development depends on an existing running resource in Azure and deployment depends on ARM templates.
  10. Versions provide development supported without disturbing the production.

Logic Apps (Standard)

  1. This is a single-tenant model, meaning no sharing of resources like compute power to Logic Apps from other tenants.
  2. The pricing is based on a hosting plan with a selected pricing tier.
  3. A portable runtime runs anywhere (within Azure, containers, on-prem, edge, and other clouds) that Azure Functions can run using the containerized single-tenant Azure Logic Apps runtime.
  4. A single Logic App can have multiple stateful and stateless workflows.
  5. Enables multiple workflows to be deployed into a single Logic App compute boundary simplifying automated deployments and CI/CD pipelines.
  6. Workflows in a single Logic App and tenant share the same processing (compute), storage, network, and so on.
  7. Stateless workflows execute completely in memory that does not need storage or persist state between actions (don’t transfer data to external storage like stateful workflows) can significantly enhance performance for request/ response scenarios. This provides, faster performance with quicker response times, higher throughput, and reduced running costs. But they could run only for a shorter time say less than 5 minutes and not like the stateful workflows that could run literally longer. Any interruptions cannot be automatically restored. Logic Apps that are part of any API call can respond faster with the use of stateless workflows.
  8. Stateless workflows
  9. Stateful workflows can store data in dedicated custom storage, thus providing data isolation.
  10. Create Logic Apps Standard
  11. As each workflow can be executed separately, Trigger and Run histories are available at the workflow level and not at the Logic App level.
  12. Calls can be exchanged between any type of workflows within the same Logic App.
  13. More than 400 managed connectors are available.
  14. Custom built-in connectors could be developed using single-tenant Azure Logic Apps extensibility framework.
  15. Support to AppInsights that helps to assess running processes, dependencies, and runtime behaviour.
  16. Logic Apps Resource types
  17. Data flowing between endpoints can be monitored using Azure Monitor.
  18. Import to Azure API Management is currently not supported.
  19. Some of the Triggers and actions, Breakpoint at debugging for triggers and UX capabilities in designers are not supported and expected to be introduced.
  20. Unlike in Consumption, where ISE is required to upload needs to have Liquid maps, XML maps, or XML schemas, an integration account is not required for the Standard resource type.
  21. Logic App (Standard) resource type to an integration service environment (ISE) nor to Azure deployment slots. Versions are deprecated in this resource type, since it is hosted on App Service plans, support for deployment slots may be expected.
  22. Logic Apps Standard

The availability of a new Standard resource type is making the Azure Logic Apps enterprise ready. This opens a lot more opportunities for application integration.