Welcome again to another Logic Apps Best practices, Tips, and Tricks. In my previous blog posts, I talked about some of the most essential best practices you should have while working with the Azure Logic App:
And some tips and tricks:
- #4 Using Scopes
- #5 Delete comments
- #6 Error handling configure run after settings
- #7 Learn from failures
- #8 Expressions nightmare
- #9 Control your connectors (API connections)
- #10 Fix connectors (or API connections)
- #11 Connectors naming convention
- #12 Choose your developer tools properly
Today I’m going to speak about another important Best practice, Tips, and Tricks that you need to know before you start to develop your Logic App solutions: Logic App (Standard) vs (Consumption):
- What and when to use one or the other
- What are the key differences between them
#13 Logic App (Standard) vs (Consumption)
Logic App (Consumption)
In a very summarized way, this is a Pay-for-what-you-use pricing model and it is completely serverless. Azure Logic Apps provides a serverless engine to build automated workflows to integrate apps and data between cloud services and on-premises systems. You pay per execution.
Logic App (Consumption), as Logic App (Standard), allows you to orchestrate tasks and define a business process for app integration, data integration, system integration, enterprise application integration (EAI), and business-to-business (B2B) communication. However, a single Logic App (Consumption) resource can have only one business logic (aka workflow).
Logic Apps are created by different customers in a multi-tenant environment or created in an ISE environment that will share the same processing (compute), storage, network, and so on. An Integration Service environment (ISE) is a fully isolated and dedicated environment for all enterprise-scale integration needs. Still, these are serverless services.
Logic App (Standard)
Again, in a very summarized way, Logic App (Standard) is almost like the opposite. It is still a cloud-based platform for automating logic app workflows that connect our apps, data, services, and systems but it is a computed-based offer. That means that Consumption hosting plans aren’t supported. You deploy to App Service hosting Plan in Azure or to a Docket Container for example. In this offer, Microsoft has 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!
- Containerized in Docker or Kubernetes environments such as AKS (Azure Kubernetes Service).
- App Service or Azure Functions for a managed PaaS experience
Previously I mentioned that a single Logic App (Consumption) resource can have only one business logic (aka workflow). Logic App (Standard) instead is a container of business flows that are called Stateless and Stateful Workflows:
- Stateful workflows should be created r used when you need to keep, review, or reference data from previous events. These workflows save the inputs and outputs for each action and their states in external storage, which makes reviewing the run details and history possible after each run finishes. Stateful workflows provide high resiliency if outages happen. Stateful workflows can continue running for up to a year.
- We can say that Stateful workflows are the equivalent of Logic App (Consumption) inside Logic App (Standard)
- Stateless workflows should be created or used when you don’t need to save, review, or reference data from previous events in external storage for later review. If outages happen, interrupted runs aren’t automatically restored, so the caller needs to manually resubmit interrupted runs. These workflows can only run synchronously. Ideal for shorter runs, faster performance with quicker response times, and higher throughput.
All the Stateless and Stateful Workflows inside a single Logic App (Standard) resource will share the same processing (compute), storage, network, and so on.
Key differences between them
There is nothing more simple than a diagram to explain some key differences between these two types of resources
|
|
Logic App (Consumption) |
Logic App (Standard) |
| Pricing and billing model |
|
Static monthly charge |
| Business process type | A single logic app can have only one business process (aka workflow). | A single logic app can have multiple stateful and stateless workflows. |
| Development tools | Azure Portal, Visual Studio, and Visual Studio Code (limited) | Azure Portal and Visual Studio Code. |
| Scalability | Logic App (Consumption) is Serverless. Nevertheless, if you use ISE you can either scale your process manually or set up auto-scaling in the portal. | Can enable autoscaling or manually scale with more virtual machine instances or a different App Service plan. |
Logic App (Consumption) advantages:
- Easiest to get started – almost all tutorials use Logic App (Consumption) using the Azure Portal
- You Pay-for-what-you-use – that works very well when using a limited number of workflows; however, with this model as the workflows increase, so does the cost.
- Fully managed by Microsoft – 100% serverless
Logic App (Consumption) using ISE advantages:
- Enterprise-scale for large workloads
- 20+ ISE-specific connectors that connect directly to virtual networks
- Predictable pricing with included usage and customer-controlled scaling
Logic App (standard) advantages:
- 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
- Fully isolate your logic apps.
- Pay only for the ASE App Service plan, no matter the number of logic apps that you create and run.
- 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.
Decide what to use
Before you start developing your integration solution you need to understand your needs and requirements to decide what king of Logic Apps you need to use. And before deciding to move or to use for everything Logic Apps (Standard) just because of the industry trend, you need to be aware that:
- Logic App (Consumption) is a more mature resource compared to Logic App (Standard). Because it is a “new” product, unknown issues may exist, as with any new product.
- Deployment requires DevOps pipeline changes, which could add challenges to setup.
- Currently, Logic Apps Standard uses existing classic consumption setup cloud connectors in addition to its own in-built connectors. However, support is currently available for a limited number of connectors. When running locally, or in a container, only built-in connectors are used.
- The fixed monthly cost may not make sense when using non-high throughput business processes.
- Start small get bigger. You can always “migrate” the Logic App (Consumption) to (Standard) or ISE when cost makes more sense.
- If you need VNet Integration then Logic App (Standard) is a must!
Are Logic App (Consumption) and (Standard) going to co-exist?
Yes! Microsoft has no plans to sunset the Logic App (Consumption) model, and neither does that decision makes any sense. Businesses can and should continue to benefit from the Logic Apps (Consumption) model but now for many scenarios like on-premises to on-premises integration or VNet support has another important model that businesses can benefit from.
Stay tuned for the following Logic App Best practices, Tips, and Tricks.
