Awfully Thorough Guide to Choosing the Best Serverless Solution, Part 2.2 : Azure Logic Apps and Durable Functions
In the previous blog post in a series we’ve examined AWS Step Functions. Now let’s see what contenders have to offer when it comes to Serverless Orchestration
Previous post in a series
Awfully Thorough Guide to Choosing the Best Serverless Solution
Part 2.1 : AWS Step Functions
Serverless Orchestration: Azure
Well, as usual when it comes to Azure, things get complicated. There are four different serverless orchestration and workflow creation services out there in Azure: Durable Functions, Logic Apps, PowerApps and Flow.
Going through this list from the top to bottom, the PowerApps platform is designed for business experts to build apps without traditional application code. It allows you to build apps in hours — not months — that easily connect to data, use Excel-like expressions to add logic and run on the web and iOS and Android devices.
Azure Flow allows you to create automated workflows between your favorite apps and services to get notifications, synchronize files, collect data and more — with no code required. The most popular Flow template is “Save Office 365 email attachment to OneDrive”.
Both Flow and PowerApps services are part of the Microsoft Low-Code Development Platform and as a such, will not be reviewed here. You can watch a Microsoft Flow and PowerApps: Advanced workflow and business process management video from the Microsoft 2019 Ignite event to get more details about those services.
Azure Logic Apps, like Flow, is a designer-first integration service that can create workflows. Both services integrate with various SaaS and enterprise applications. Microsoft Flow is built on top of Logic Apps. They share the same workflow designer and the same connectors, but while Flow’s target audience is office workers and business users, Logic Apps is intended for much more technology sophisticated professionals.
As such, it supports more advanced integrations, source control, versioning, automated testing and so on.
And last but not least, Azure Durable Functions is an extension of Azure Functions that lets you write stateful functions in a serverless environment. The extension manages state, checkpoints and restarts for you, and it has nothing to do with declarative programming — everything is done in code.
In this review we’ll look at Logic Apps and Durable Functions — these two together are the closest alternative to what AWS Step Functions can do.
Logic Apps allow developers to design workflows that articulate intent via a trigger and series of steps, each invoking an App Service API app whilst securely taking care of authentication and best practices like durable execution.
Durable Functions are an extension of Azure Functions that lets you write stateful functions in a serverless environment. The extension manages state, checkpoints, and restarts for you.
Benefits and Use Cases
Logic Apps allow you automate business processes and workflows in your organization visually without any line of code. Think about a bunch of out-of-the-box connectors for services like Salesforce, Office 365, Twitter, Dropbox, Google services and more that can run as a single workflow to implement some business logic — this short video demonstrates the use case.
Once a new Logic App is created, you can choose the connectors to add or leverage one of the dozens of available templates. Here is an example of a typical scenario for an average corporate IT professional:
Once you choose a blank Logic App you will see a neat white panel where you can start building your application using various control statements (i.e., “if..else,” “switch” and “foreach” loops) that can control a workflow and orchestrate a number of Azure services such as Azure Functions.
Working with Durable Functions is quite a different story. As already mentioned, it has nothing to do with declarative programming — it is an extension of Azure Functions designed with the following use cases in mind:
· Functions Chaining — A sequence of functions executes in a specific order and the output of one function is applied to the input of another function.
· Fan Out/Fan In — You execute multiple functions in parallel and then wait for all functions to finish. Often, some aggregation work is done on the results returned from the functions.
· Async HTTP APIs — Coordinating the state of long-running operations with external clients.
· Monitor — Flexible, recurring process in a workflow. An example is polling until specific conditions are met.
· Human Interaction — Involving humans in an automated process is tricky because people aren’t as highly available and as responsive as cloud services. An automated process might allow for this by using timeouts and compensation logic. An approval process is an example of a business process that involves human interaction.
· Aggregator — Aggregates event data over a period of time into a single, addressable entity. In this pattern, the data being aggregated may come from multiple sources, may be delivered in batches or may be scattered over long-periods of time.
All this is possible because of one single reason — you can use Durable Functions to write stateful functions in a serverless environment. Refer to the official Azure Durable Functions patterns and technical concepts blog post to deep dive.
Bottom line — it is easy to see that Step Functions is still far behind the Azure serverless orchestration services when it comes to use cases and the target audience. Azure addresses both non-technical professionals and software engineers and gives both plenty of tools to use, as we’ll discuss further.
Tooling and Debugging
If you build a Logic App, you will use a web-based Designer tool (a part of the Azure Portal). It obviously cannot be compared to any IDE and is not compatible to any complex workflows. Even this neat small app,when expanded, is very difficult to use for editing and developing and you will constantly need to zoom in/out while doing this.
Tapping “Code View” results in a huge JSON file (which is actually a Azure Resource Manager template) — and it really feels like a great relief not to deal with it manually. Step Functions product managers should definitely give this a try see how it makes a difference.
It is also possible to create (but not to debug) Logic Apps on your local machine. Get yourself Visual Studio (a free Community Edition is enough) and read Quickstart: Create automated tasks, processes and workflows with Azure Logic Apps — Visual Studio to learn more about it. Again, local debugging is not supported, which is an obvious drawback.
Building Logic Apps on top of the Resource Manager allows you to also manage Logic Apps versioning — you just add the ARM file and you are done.
And what about Durable Functions? Well, since it’s an extension of Azure Functions, everything that is right for the latter, is right for the former. See my previous post to get more details. Also, this Complete Guide to Unit Testing Durable Functions with VS Code post on Hacker Noon is pretty helpful.
Azure Logic Apps integrates with various services (not only Azure services, unlike Step Functions which supports AWS services only) through connectors. There are hundreds of connectors and if you want to integrate with a service or API that doesn’t have a connector, you can either directly call for the service over a protocol such as HTTP or create a custom connector. It’s worth mentioning that creating a custom connector is more than a software development task and you will go through a long process to get your connector approved by Microsoft. This Connectors for Azure Logic Apps blog post by Azure provides more details.
When it comes to Durable Functions, it makes sense to list supported languages rather then services. So here we go:
- C#: Both precompiled class libraries and C# script.
- F#: Precompiled class libraries and F# script. F# script is only supported for version 1.x of the Azure Functions runtime.
Monitoring and Logging
There is a huge mess in terms, products and abbreviations when it comes to Azure logging services. Microsoft Operations Management Suite has been replaced by Log Analytics, which has been replaced by Monitor Logs — but only in tutorials — while in Azure Portal it is still Logs Analytics Workspace.
Whatever name it goes by, Logic Apps has pretty impressive logging and monitoring capabilities, including history of runs and tons of other useful information.
Azure’s official Monitor logic apps with Azure Monitor logs blog post provides a comprehensive overview of those capabilities.
Durable Functions has the same options as Azure Functions (yes, Applications Insights) and more, which are mostly related to the orchestration of infrastructure events. Read Diagnostics in Durable Functions in Azure and Durable Functions Logging Best Practice posts to drill down into the details.
Performance and Scaling
Logic Functions has various limits both in size of the application and in application performance. The list is long (it is very long, actually) and includes more than 10 categories with dozens of items in every category. To name a few, there are Definition Limits (i.e., the amount of switch scope case limits and number of triggers per flow), Duration Limits, Throughput Limits and others. For some reason, Throughput Limits are measured per five minutes: for example there are a max 300K executions per five minutes.
The tricky thing is there are also scale limits for every connector in Logic Apps and you never know which one will kick in as a bottle neck. This (draft) blog post describes such a case. Considering all the above it wouldn’t be a good decision to make any Logic App a part of your product critical path.
Durable Functions leverages Azure Storage to maintain a state, therefore, to understand the scale behavior, you have to understand some of the details of the underlying Azure Storage provider. When it comes to auto scale, the behavior depends on which hosting plan is being used. As with everything in Azure, it is complicated. Read this Performance and scale in Durable Functions Azure post to learn more.
It might sound surprising, but the Logic Apps security model is much more developed and mature then the Azure FaaS one. It is possible to hide Logic Apps behind the Azure API Gateway (API Management), secure access to HTTP request triggers with SAS, IP restrictions and OAuth, restrict users’ access to runs history and more. Read the recent Secure access and data in Azure Logic Apps for more details.
The security model of Durable Functions is the same as Azure Functions’ and you can read about it here
As for any serverless service, there are no up-front costs and you pay per execution. For Logic Apps, bot connectors (which are divided into categories — built-in, standard and enterprise) and actions are metered. Unfortunately, this causes the ridiculous situation when your well-structured Logic App with multiple steps will cost you more than one big Logic App with a single step — unless you are using built-in connectors.
The overall model is too complex to discuss fully here, so please go to the Logic Apps pricing page for details. This Azure Logic Apps Pricing 2018. Do you still need to be careful about costs? post, while somewhat old, still provides a great analysis and live run of various loads using the Logic Apps pricing model and is definitely worth a read.
Overall, pricing is much easier with Durable Functions — you are billed the same as with Azure Functions (see Azure Functions pricing for more information), or at least you’re supposed to be. Since Durable Functions leverages Azure Storage service, you may end up a monthly bill for hundreds dollars for storage only — see this, still open GitHub issue. Be aware!
Wrap Up and Further Reading
Microsoft has invested a lot in serverless orchestrations services. While two of these options target citizen developers, Logic Apps and Durable Functions look like valid tools for professional backend developers. The former is more for fast and codeless services integrations and should be used for high-load and performance sensitive tasks, while the latter provides an excellent out-of-the-box solution for various scenarios that cannot be held by Azure FaaS service alone.