Analyze the decision criteria

In the previous step you learnt about identifying the product options for Azure serverless technology. In this step you will learn about analyzing the decision criteria for using Azure serverless technology.

With two viable serverless options, it can be difficult to know which is the best one for the job. In this unit, we’ll analyze the criteria that experts employ when they’re choosing a serverless service to use for a given business need. Understanding the criteria can also help you better understand the nuanced differences between the products.

Do you need to perform an orchestration across well-known APIs?

As we noted previously, Azure Logic Apps was designed with orchestration in mind, from the web-based visual configurator to the pricing model. Logic Apps excels at connecting a large array of disparate services via their APIs to pass and process data through many steps in a workflow.

It’s possible to create the same workflow by using Azure Functions, but it might take a considerable amount of time to research which APIs to call and how to call them. Azure Logic Apps has already componentized these API calls so that you supply only a few details and the details of calling the necessary APIs is abstracted away.

Do you need to execute custom algorithms or perform specialized data parsing and data lookups?

With Azure Functions, you can use the full expressiveness of a programming language in a compact form. This lets you concisely build complex algorithms, or data lookup and parsing operations. You would be responsible for maintaining the code, handling exceptions resiliently, and so on.

Although Azure Logic Apps can perform logic (loops, decisions, and so on), if you have a logic-intensive orchestration that requires a complex algorithm, implementing that algorithm might be more verbose and visually overwhelming.

Do you have existing automated tasks written in an imperative programming language?

If you already have your orchestration or business logic expressed in C#, Java, Python, or another popular programming language, it might be easier to port your code into the body of an Azure Functions function app than to re-create it by using Azure Logic Apps.

Do you prefer a visual (declarative) workflow or writing (imperative) code?

Ultimately, your choice comes down to whether you prefer to work in a declarative environment or an imperative environment. Developers who have expertise in an imperative programming language might prefer to think about automation and orchestration from an imperative mindset. IT professionals and business analysts might prefer to work in a more visual low-code/no-code (declarative) environment.

Use Azure Functions

Data about each product that’s sold at Tailwind Traders is packaged as a JSON message and sent to an event hub. The event hub distributes the JSON message to subscribers, which allows various systems to be notified.

Tailwind Traders wants to upgrade its e-commerce site to include real-time inventory tracking. Currently, the website updates product availability nightly at 2:00 AM. A Windows service that’s written in C# contains all of the necessary logic to:

• Retrieve the messages.
• Parse the JSON.
• Perform a lookup across multiple databases to find additional product information.
• Potentially, send notifications to the purchasing department so that they can reorder quantities that fall below certain levels. The Windows service runs in a virtual machine that’s hosted on Azure.

Most of the time, this system works fine. However, some products are in high demand, and some products are kept in low quantities at each store. Several times a day, customers drive to a store to pick up an item only to find that it’s no longer in stock.

Instead of running the algorithm nightly, the company wants to run the inventory updater each time a product is purchased.

Which service should you choose?

Because the Tailwind Traders developers team has already written the logic in C#, it would make sense to copy the relevant C# code from the Windows service and port it to an Azure function. The developers would bind the function to trigger each time a new message appears on a specific queue.

Why not choose Azure Logic Apps?

It’s possible to implement the same logic in Azure Logic Apps. However, because the team has already invested time in building the service in C#, it can use the same code in an Azure function.

Use Azure Logic Apps

Tailwind Traders sends its customers an invitation to participate in a customer satisfaction survey randomly after a purchase. Currently, the customer satisfaction results are aggregated, averaged, and charted. However, its customer service department sees an opportunity to reach out proactively to customers who provide low scores and leave comments with a negative sentiment.

Ideally, negative customer satisfaction scores would trigger a customer retention workflow. First, a sentiment analysis would be generated based on the free-form comments, an email would be sent to the customer with an apology and a coupon code, and the message would be routed to the Dynamics 365 customer service team so that it could schedule a follow-up email.

Unfortunately, no Tailwind Traders developer resources are available to take on this project. But the customer service team works with several cloud and IT professionals who might be able to construct a solution.

Which service should you choose?

In this scenario, Azure Logic Apps is likely the best solution. A cloud or IT professional could use existing connectors to perform a sentiment analysis by using the Azure Cognitive Services connector, send an email by using the Office 365 Outlook connector, and create a new record and follow-up email by using the Dynamics 365 customer service connector.

Because Azure Logic Apps is a low-code/no-code service, no developers are needed. A cloud or IT professional should be able to build and support this workflow.

Why not choose Azure Functions?

Although it’s possible to build the entire solution by using Azure Functions, this approach might be a challenge if no software developers can be committed to this project.

This is an ideal scenario for Azure Logic Apps. Connectors already exist for each of the steps outlined in the workflow. It would take quite a bit of research, development, and testing for a developer to build a solution that utilizes all these disparate software systems.

You are almost at the end of this activity. When you are ready click on Mark as complete and then Next to continue on to the Knowledge check.