Dynamics 365 CE integrations scenarios with Azure Functions

Over the past year or so, our team has worked on almost exclusively cloud-based Dynamics 365/CRM implementations. Common requirements haven’t changed, long running batch processes, integrations with external systems, maintenance jobs etc. We have found ourselves using Azure Functions in almost all projects for the past year. In this article, I define what Azure Functions, how they are priced, and I provide some of the use cases that we have seen when it comes to Dynamics 365/CRM integrations.

What are Azure Functions

Definition

Azure Functions is commonly referred to as serverless computer service. What this means is that it is a cloud-based service that allows you to run code on demand without having to deploy it to any infrastructure, and to only pay for the usage that you make. Microsoft developed this Framework to allow us to write code in a language of your choice (C#, JavaScript, PowerShell, PHP, Python), have it do all sorts of cool stuff, deploy it somewhere and run it on demand. The notion of “on demand” is broad and it takes us to the triggers discussion. Functions can run a wide set of triggers, including Timer, HTTP call, Webhooks, Service Bus, Queue Storage and others.

Pricing model

The pricing model is relatively straight forward. There are two models. The first one is the App Service plan. I will not spend too much time on this one. App Service plans are the type Azure services that you subscribe to when you want to host a web application (web site, web service etc.). If you already have such a subscription, you can simply deploy your Azure Functions into it at no extra cost.

The other pricing model is a consumption based model. This model takes two components to do pricing:

  1. Number of executions: any time a function is executed (i.e. triggered), it counts as an execution
  2. Resource consumption (in GB-s): any time a function runs, the platform calculates the amount the memory (RAM) that is used and for how long. This translates into a number of Gigabytes-seconds (GB-s) that you have to pay for. It is also a number that is sometimes hard to predict because you cannot easily know how much memory your piece of code will require when it runs.

There are monthly free grants of 1M executions and 400,000 GB-s resource consumption. After that, you start to pay a certain amount by execution and by GB-s used. Prices can vary slightly based on the region that you are in.


In most cases, it tends to be the most adapted for business scenarios that we have worked on, meaning the price that you pay and the guarantied scale for performance outweighs the benefits of buying let’s say an inexpensive App Service to reduce your monthly cost.

Dynamics 365/CRM and Azure Function use cases

As we’ve worked on CRM Online projects, we have often faced scenarios in which we have considered and often used Azure Functions. I grouped them in use cases.

  • Recurring jobs: these types of processes are typically built using console apps running as scheduled tasks, SSIS Jobs or sometimes even recurring Dynamics 365/CRM workflows. It could also be a DevOps PowerShell script that developers run every day from their workstations. Azure functions with timer triggers work well to address many of these scenarios.
  • Reusable business logic: when you have a bloc of code that is called from multiple plugins/integration jobs or custom applications, lots of times you will find code being copied manually or file references use heavily. It makes sense to consider moving the code to an Azure function with an HTTP trigger and have the function being called by multiple processes.
  • Plugin scenarios impacted by sandbox limitations: there are plenty of restrictions when you run your plugins or custom workflow activities in Sandbox mode. For example, referencing external libraries is not officially supported, running processes that last more than 2 minutes, calling web services with complex authentication, writing on disk etc. Most of the limitations are completely removed when working with Azure Functions.
  • Reducing the cost of alternative tools: In all the scenario above, there is usually some financial impact with licences (Windows Servers, SQL Server, SSIS Connectors etc.). The local servers also have to be monitored and maintained. Azure functions remove some the servers and tools licensing cost and shifts it to a “pay per use” model while suppressing the need to maintain servers on premise.

These use cases along with resource skills availability have made us use seriously consider Azure Functions in our solutions architecture for the past year or so. I strongly recommend taking a look at them if you haven’t.

Getting started…

I had the pleasure of presenting this content on an xRMVirtual User Group webinar. The slides are available below.

Check back for the link to the webcast, I will publish it when it makes it to the website. In the mean time, here are some articles to get started with Azure Functions and Dynamics 365.

Getting started with Azure Functions here.
Integrating D365 with Azure Functions – Part 1 and Part 2

Enjoy!

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s