Kentico And Azure Integration Possibilities — Part 2 — Azure Functions And Logic Apps
A brief serverless introduction
I start with the assumption that most of you have been bombarded with serverless technologies for the last few years, but I would at least like to briefly touch on this topic for those who are not that into hype.
Serverless is an often misunderstood term and it does not mean your code doesn’t run on a server, that would be very improbable (but how amazing would that be?). It just means that you don’t have to worry about the server your code is running on. For those interested in the details on this topic, Sam Newman had an excellent talk on serverless on last years GOTO conference in Amsterdam.
So, continuing on from the formalities..
Why consider Functions and Logic Apps
Azure Functions and Kentico
An obvious first benefit, given the nature of serverless technologies, is that you don’t have to worry about the infrastructure your code is running on. That is all managed by our dear friends at Microsoft.
This reduces the costs of operations teams and allows them to focus on more important things. In addition, both developers and devops can focus more on the business logic and less on the deployments, versioning, administration and all other rituals that come with development.
The €uro topic
At first glance functions and logic apps might seem as an additional cost on top of regular hosting costs, however if used for the right business cases they can reduce costs significantly.
If you look at the pricing page for Azure functions, you can see that it starts at 20 dollar cents per one million executions, which is approximately 8 executions per minute if calculated over a period of a month. Compared to an additional App Service for scheduled or fire-and-forget operations application this is negligible.
What to use them for
There is a vast array of use cases for Azure serverless functions both in Functions and Logic Apps form. However the areas where they shine the most are event driven actions, workflows, and scheduled operations.
- Periodic cleaning of old blob storage files
- Image resizing on upload
- PDF Generation on request
- Various External Synchronizations
Are perfect candidates for Azure Function usage. These are all relatively expensive operations that could use valuable resources on your application that are instead delegated to the Function.
How to start using functions
Creating an Azure function
To create an Azure function, first, you need to navigate to your subscription, and press the “Create a resource” button on the top of your Azure portal, search for Function App and press the create button:
Now you will be presented with a few options, which i will explain one by one.
- Name — This is the name give to your function — pick something fancy
- Subscription — Usually no need to change this.
- Resource Group — Pick a resource group or create a new one. Resource groups are a great way to group your resources (databases, app services etc.) on Azure.
- OS — Azure functions can run on either Windows or Linux.
- Hosting Plan — This is an important choice to make while considering using functions. Consumption plan will probably be the default choice for you. This is a pay-per-execution model, if you function never runs, you don’t pay for it, simple as that. The App Service plan might also be useful for you in some cases, for example if you have an underused App Service plan already, which is the case more often than you might think.
- Location — Pick a location close to where your App is hosted, usually he same region.
- Storage — The code for the function needs to be stored somewhere. This is where it is stored. You can re-use an existing storage to reduce costs, or create a new one. Storage on Azure is relatively cheap.
After you’ve created your function app, Azure will take some time to deploy and set up everything needed to run it for you:
Once our Microsoft friends have provisioned everything, you can access your function app and create a new function.
When first creating a function you will be presented with a choice of development model, and a deployment model.
You can pick any model that suits you, they all have their pros and cons, however I will go with the VS Code environment and the direct push deployment model.
In you development environment, for example purposes create a new QueueTrigger function and leave the default code in for now. This should be sufficient to get it working from Kentico.
Triggering your function from Kentico
Our Azure Function has a storage account connected to it for another reason other than storing the actual code. Azure storage accounts have a Queue integrated into it which is a great way to decouple our Kentico app from our function and send “Commands” to our it.
The easiest way to add an item to our queue is using the Microsoft provided client library by running a Kentico scheduled task, so let us do that.
In the above screenshot you can see how to connect to the Azure storage and queue an example JSON payload which our function will pick up and process.
When we register our scheduled task and run it from Kentico we see that it is added to the queue and that our function picks it up after a short while (in seconds):
This all might seem like over-complicating a simple operation, but the benefit of queuing up work this way is that your Kentico scheduled task won’t actually do any processing. It will just add an item, or a bunch of items to a queue and our function will do the rest.
This saves a large amount of resources on the Kentico app in cases like syncing data to an ERP or CRM, deleting blobs on Azure Storage and any other IO intensive operations.
A note on Logic Apps
The example with the function is a very basic example of what can be done with Azure serverless resources. Logic Apps are a step away from custom development into more of a workflow design direction and they can be triggered in the same way functions can, but require little to no development.
You could consider Logic Apps for advanced notification scenarios, moving Jira tickets around, syncing files between different services, posting to multiple social networks etc.
The array of possible connectors is very vast and should cover most if not all services your clients might use.
Conclusions and final notes
If you haven’t already, check out the first part of the series about Kentico and Azure :