Azure Logic Apps vs. Microsoft Flow
Why not both?
Join the DZone community and get the full member experience.Join For Free
These days, you can’t go to a Microsoft conference where the question of “What is the difference between Microsoft Flow and Azure Logic Apps?” isn’t asked. For many people, they think the answer is binary; you need to use one or the other. While people have preferences, and perhaps even biases, it is important not to rule the other technology out, as you are likely missing out on opportunities for your organization.
You may also enjoy: When to Use Logic Apps and Azure Functions
When Microsoft has answered the Azure Logic Apps vs. Microsoft Flow question in the past, personas generally played a role in deriving an answer. When it comes to “Power users” or even “Citizen Developers,” Microsoft Flow is generally identified as the tool of choice, in part due to it being the targeted audience for why the tool was created.
For this segment of the audience, the debate is less tense.
Where the debate starts to heat up is in the area of more technical people. Generally, this segment of the user population can be categorized as:
- IT Pros who have strong technical backgrounds, perhaps in Office365 (SharePoint), Dynamics365, PowerApps or other related technologies. For some people within this population, Flow is seen as a tool to solve all problems. However, there may be a tendency to overuse Flow, when a Logic app can solve the problem, out-of-the-box. For example, looking to modify the code behind the workflow, needing a longer workflow run duration, parsing a CSV or flat file, to name a few scenarios.
- Pro Devs live in IDEs like Visual Studio and may come from BizTalk, API Management or Message Oriented Middleware backgrounds. For some people within this population, Flow is perceived as a "toy" that should be used for personal productivity. For example, sending a notification when your boss emails you. Since Azure Logic Apps can perform most of the functions that Microsoft Flow can, Logic Apps may be overused when some workflow automation can be performed by others within the organization as an opportunity to scale automation efforts.
In the rest of this blog post, I will try to demystify some of these perceptions about both tools.
While Microsoft Flow, runs on top of Azure Logic Apps there are some differences that exist. In this section, we will focus on some of the major capabilities and draw attention to some areas where a set of features provide Microsoft Flow with clear differentiation.
Microsoft Flow is technically an integration Software-as-a-Service. Abstractions have been created by the Microsoft Flow team that lowers the barrier of entry for users to start building with it. As a result, “makers” do not require an Azure subscription to build flows, even though their flows do run in Azure as a logic app, underneath the hood.
Makers typically gain access to Microsoft Flow through Dynamics365 or Office365 entitlement. This provides users with a monthly quota and access to specific features. Standalone plans and additional SKUs are also available for purchase.
The Microsoft Flow product group resides within the Business Applications Group, where it is closely aligned to the roadmaps of its organization’s counterparts: PowerApps, PowerBI, and Dynamics365.
There are two types of flows that makers can create:
- Automated Flows, which are free-form workflows, that resemble Azure Logic Apps.
- Business Process flows (BPFs), which have their roots in Dynamics and represent a very structured business process with different stages.
Both of these types of flows can be constructed from the Microsoft Flow maker portal which is available here. For the purposes of this post, we are going to focus on automated flows as BPFs do not have a Logic Apps equivalent.
Microsoft Flow includes Templates which act as common blueprints that allow makers to get started quickly based upon a pattern that has been previously vetted by Microsoft. These templates are provided by the community, the Microsoft Flow Product Group (PG), other PGs like Cloud App Security, and third parties, such as those that create their own connectors.
Connectors are a big part of the Microsoft Flow offering, and there are over 230 connectors available inflow, both from Microsoft and third parties. While many of these connectors are for SaaS- or cloud-based systems, there are some on-premises connectors that can be used in conjunction with the on-premises data gateway to access local services.
Connectors are divided into two categories, Standard and Premium. Standardconnectors are available with entitlements that come from other licensing plans, such as Office365. Premium connectors require additional licenses, either through other vehicles like PowerApps or Dynamics, or standalone. There are also some connectors that are exclusive to Microsoft Flow including Approvals, Buttons (physical and virtual), and native mobile notifications.
Approvals are a big part of the Microsoft Flow offering, providing an authenticated experience that includes mobile notifications through the Microsoft Flow mobile app. Approvals can also be responded to from the Microsoft Flow Approval Center found in the maker portal and from the Outlook email client. Approval history is stored within the Common Data Service (CDS), which is a core data store for PowerApps and Microsoft Flow Solutions.
Microsoft Flow includes several first-party integrations. These integrations align with where flow users typically like to work: SharePoint Online, OneDrive for Business, Dynamics365, Excel, and Microsoft Teams, to name a few. In addition, there are some third-party integrations with hardware vendors like Flic and Bttn.
Application Lifecycle Management
In November 2018, Microsoft announced the ability to include multiple flows and canvas apps within a single “solution” that can be transferred from one environment to another. As of this writing, there are some gaps in the areas of including custom connectors, parameters, connections, and Azure DevOps integration. However, Microsoft has plans to further invest in these areas.
Microsoft continues to invest in this area as well. Core governance capabilities include Admin Management Connectors, Data Loss Prevention (DLP) policies Office365 Security and Compliance center, and Admin Analytics.
In addition to all of the features we have mentioned in this post already, there is another feature that impacts both Microsoft Flow and Azure Logic Apps. This feature allows you to export your flow, from the Microsoft Flow maker portal and then import it into Azure as a Logic App, through the Azure portal. This feature works in most scenarios, except when Azure Logic Apps doesn’t have the relevant feature including button triggers or approvals.
Azure Logic Apps
Azure Logic Apps is an Integration Platform-as-a-Service (iPaaS). It is a consumption-based billing service, which requires an Azure Subscription in order to build and run Logic Apps. More recently, the Logic Apps team has also released, in the preview, a dedicated capacity version called Integration Service Environment (ISE). Azure Logic Apps is part of the Azure Integration Services platform, which includes Azure API Management, Service Bus, and Event Grid.
Azure Logic Apps ISE includes VNet connectivity which allows customers to create direct connections to their on-premises assets without the use of an on-premises data gateway. It also includes the ability to have static outbound IP addresses, custom inbound domain names, isolated storage, scale-out/in capabilities with a flat cost billing model.
There are many similarities between the connectors available in Microsoft Flow and Azure Logic Apps. While Microsoft Flow has buttons and approval connectors, Azure Logic Apps has enterprise connectors like SAP, IBM MQ and B2B support for AS2 and EDIFACT.
There is no concept of standard and premium connectors inside of Logic Apps, but customers who have deployed an ISE can take advantage of a specific sub-set of connectors that will connect to resources on their VNet by using an ISE version of the connector. Organizations that do not go the ISE route can still connect to on-premises data sources using the on-premises data gateway.
Since Azure Logic Apps focuses on enterprise integration, it includes features that pro developers expect, including support for Visual Studio and Visual Code is in preview with IntelliSense support. Designer support is currently not available.
Enterprise integration projects typically require data transformation support. To address these requirements, Azure Logic Apps supports typed XML schemas, flat-file encoding/decoding, XML transformations, and JSON transformations. Using these capabilities requires an Integration Account which acts as a storage container for these artifacts. Integration Accounts also enable Trading Partner Management scenarios and allow for the management of partners and agreements.
Since Logic Apps is an Azure service, developers are able to take advantage of Azure Monitoring, which will raise alerts when there are failures that occur within Logic Apps or other Azure services. Alerts can be sent to interested stakeholders via email or a Logic App webhook can be called where a business process can be orchestrated which can include logging tickets in IT Service Management tools like ServiceNow.
Logic Apps provides a run-history feature enabling you to examine specific runs in full detail. Also, you can filter this history, based on a period and the resulting run status. Furthermore, Logic Apps integrates with Operation Management Suite (OMS) in Azure – for instance, with a one-button click, you can enable integration with OMS, where you can search for tracked properties.
You can also leverage a third-party solution like Serverless360 to monitor your Logic Apps. Serverless360 offers even more capabilities than monitoring – you can also operate, manage Logic Apps and also get notified on the failure of Logic App run action in near real-time with Serverless360.
The governance features in Azure differ from those provided in Microsoft Flow, in part due to the personas that are typically involved in building solutions and that getting access to Azure is an "opt-in’" activity, whereas all Office365 licensed users have maker privileges in the default Microsoft Flow environment. Even with access to the Azure Portal, Azure Identity Access Management (IAM) rules exist which can grant, or prevent, access from creating or accessing Logic Apps. These access rules can be applied at the individual Logic App level, or at the Resource Group level.
Data Loss Prevention
Data Loss Prevention (DLP) rules do not exist within Azure Logic Apps, as access to the Azure Portal is seen as a barrier in itself. Analytic capabilities are fulfilled through Log Analytics integration that sends logic app technical diagnostic information to the Log Analytics service, and a solution template exists that includes out-of-box charts. Developers can also send custom events to Log Analytics by providing custom tracked properties within their logic app configuration.
Logic Apps also provide a longer execution duration of 90 days and allow developers to control the run history data retention.
Choosing the Right Tool
As we have discovered, there are a lot of shared capabilities between Microsoft Flow and Azure Logic Apps. There are also some subtle differences between the two, but they can play a significant role in determining which is the best tool for the job. Ultimately, tooling should be selected based upon organization design and the complexity of the requirements.
I firmly believe that we have a requirement-complexity spectrum that plays a major role in deciding which tool is more appropriate. Naturally, this spectrum begins with simpler use cases, that likely involve personal productivity and extend to regulatory and compliance use cases.
If we map our requirements complexity to Microsoft Flow and Azure Logic Apps, we will discover that Microsoft Flow is better suited to deal with requirements that exist on the simpler spectrum, whereas Logic Apps better aligns to dealing with requirements that tend to be more complex in nature.
But by no means does this undermine either tool! Part of the reason why Microsoft Flow was created was to democratize cloud-based workflow and automation. This represents a huge opportunity and I have highlighted this on the following image where I identify an “Organization’s Scaling Opportunity Zone.” In this area, organizations can take advantage of low code/no-code configuration and address a broader range of automation problems than if they were depending solely on centralized pro dev integration team to fulfill these requests.
This messaging doesn’t diminish the value that pro developers/integrators bring to the organization, either. With the increasing amount of SaaS applications that are available in the market and the growing need for B2B data exchanges, there is no shortage of work for these people. In many circumstances, data may be sensitive and need to be restricted through Azure IAM rules. In addition, organizations may have regulations such as SOX, which require segregation of duties and strict change management requirements which are better addressed through Azure Logic Apps.
Scaling Your Organization
If you were looking for a definitive answer of which tool is “better,” you won’t find it in this post. Ultimately, both tools provide tremendous benefits within an organization. The true winner is an organization that identifies how to use each tool to deliver value to the organization. At the end of the day, people should consider the desired business outcomes first, then figure out what is the best tool that helps achieve those outcomes, while putting their personal biases aside.
Published at DZone with permission of Kent Weare. See the original article here.
Opinions expressed by DZone contributors are their own.