Recently we’ve shared very briefly about a business-technical seminar – Azure Services to Quickly Build Powerful Solutions. Nevertheless, I think some of the topics we covered, deserve a few more words of their own. The first service we discussed was Azure Functions. We did so by looking at it them in three main aspects:
- An overview of their characteristics
- Some of the applicable scenarios and key features
- Pricing models
We wanted to help business-technical professionals to understand when and if they should use Azure Functions.
Overview of key Azure Functions Characteristics
Are you deciding whether or not to use Azure Functions in some of your solutions? It would definitely help to know a bit more about their philosophy. For instance:
- They aim to provide developers with the means to write less code and care less about infrastructure maintenance;
- The logic inside each function usually gets executed as a reaction to an external trigger. It could be a message received, filed created, item queued, HTTP endpoint called, etc.
- Although they’re supposed to ease developers in a way, unlike some other Azure Services (i.e. Logic Apps) they definitely require coding skills;
- The good thing about the coding aspect though is that we have a bunch of options here. You could use either C#, JavaScript, Java, Python, PowerShell, or F#.
- When we code we should mind the default stateless nature of the functions (or sue Durable Functions)
- We could also rely on auto-scaling. This way we lower the risk of not being able to execute the necessary logic in case if increased requests
Scenarios and Features
As long as we believe that a certain task could be designed and coded in the context of an event-driven serverless platform, then Azure Functions could be a solution for us. Once decided, what we could implement on top of them… well, I might exaggerate a bit, but will not be that far from the truth that “sky is the limit” here. For instance, we could:
- Build a web API
- Process file uploads
- Run scheduled tasks
- Create reliable message queue systems
- Process data in real-time
Hosting/Pricing Models
Now, if you’ve decided whatever you want to do should end up as an Azure Function, you’d need to decide how to host it. If you’re not going to use your own infrastructure and intend to go with the Azure-default approaches, you’d need to consider either of the following three:
- Consumption Plan
- Your function should finish quickly (up to 10 mins) or you’ll get a time out
- You get billed only when your function is running
- The billing is based on the number of executions per execution time and allocated memory
- Premium Plan
- It also scales automatically
- You have at least 60 mins of guaranteed runtime of your function, and no limitations if you need to exceed it.
- “warm” instances (i.e. once triggered your functions will wake up much quicker)
- You get billed at least for a minimum cost per active plan
- The billing is based on the number of core seconds and allocated memory across your instances
- App Service Plan (Dedicated)
- Auto-scaling is available but should be enabled (configured) manually
- You’d need to turn the “AlwaysOn” configuration for service
- You can rely on more runtime compared to the limitation of the Consumption Plan. Here it is 30 mins.
- You’d need to pay the whole App Service Plan cost, no matter how much time your function was running
In case you’re considering the use of Azure Function, here is a good starting point: https://docs.microsoft.com/en-us/azure/azure-functions/functions-create-your-first-function-visual-studio and there is also a good learning path which could get you up to speed: https://docs.microsoft.com/en-us/learn/paths/create-serverless-applications/