When would I prefer Azure Functions to Azure Container Instances, considering they both offer the possibility to perform run-once tasks and they bill on consumption?
Also, reading this Microsoft Learn Module:
Serverless compute can be thought of as a function as a service (FaaS), or a microservice that is hosted on a cloud platform.
Azure Functions is a platform that allows you to run plain code (instead of containers). The strength of Azure Functions is the rich set of bindings (input- and output bindings) it supports. If you want to execute a piece of code when something happen (e. g. a blob was added to a storage Account, a timer gets triggered, ....) then I definitely would go with Azure Functions.
If you want to run some container-based workload for a short period of time and you don't have an orchestrator (like Azure Kubernetes Services) in place - Azure Container Instances makes sense.
Take a look at this from Microsoft doc
Source: https://learn.microsoft.com/en-us/dotnet/architecture/modernize-with-azure-containers/modernize-existing-apps-to-cloud-optimized/choosing-azure-compute-options-for-container-based-applications
If you would like to simplify application development model where your application architecture has microservices that are more granular, such that various functionalities are reduced typically to a single function then, Azure functions can be considered for usage.
In case, the solution needs some extension to existing azure application with event trigger based use cases , the azure functions can be better choice . Here, the specific code (function) shall be invoked only for specific event or trigger as per requirement and the function instances are created and destroyed on demand (compute on demand - function as a service (FaaS) ).
More often, the event driven architecture is seen in IoT where typically you can define a specific trigger that causes execution of Azure function. Accordingly, Azure functions have its place in IoT ecosystem as well.
If the solution has fast bursting and scaling requirement, then container Instances can be used whereas if the requirement is predictable scaling then, VMs can be used.
Azure function avoids allocation of extra resources (VMs) and also the cost is considered only when the function is processing work. Here, we need not take care of infrastructure such as where the code is going to execute, server configuration, memory etc. For ACI, the cost is per-second where it is accounted based on the time the container runs - CaaS(Container As A Service).
ACI enables for quickly spawning a container for performing the operation and deletion of it when done where the cost is only for few hours of usage rather than a dedicated VM which would be of high cost. ACI enables one to run a container by avoiding dependency on orchestrators like Kubernetes in scenarios where we would not need orchestration functions like service discovery, mesh and co-ordination features.
The key difference is that, in case of Azure function, the function is the unit of work whereas in container instance, the entire container contains the unit of work. So, Azure functions start and end based on event triggers whereas the microservices in containers shall get executed the entire time.
The processing / execution time also plays a critical role where if the event handler function consumes processing time of 10 minutes or more to execute, it is better to host in VM because the maximum timeout that is configurable for functions is 10 minutes.
There are typical solutions that utilize both the functionalities such that Azure function shall be triggered for minimal processing / decision making and inturn can invoke container instance for specific burst processing / complete processing.
Also, ACI along with AKS form a powerful deployment model for microservices where AKS can be for typical deployment of microservices and ACIs for handling the burst workloads thereby reducing the challenges in management of scaling and ensuring effective utilization of the per second usage cost model.
Related
I'm currently using an Azure Premium Service App (P3v3). I found that my function needs some boost, so I decided to look at how I can configure scaling.
I found two available options:
Set FUNCTIONS_WORKER_PROCESS_COUNT in the configuration section
Configure the number of instances in Scale-Out menu
But what is the difference between instances and workers? Haven't found any information about that or how it can affect costs.
what is the difference between instances (Scale-Out menu) and workers (FUNCTIONS_WORKER_PROCESS_COUNT)?
These are Microsoft Documentations to understand Workers and Instances in terms of Cost Management (Billing) and Functionality:
MSFT Sources of FUNCTIONS_WORKER_PROCESS_COUNT:
Azure Functions - Functions App Settings - functions_worker_process_count
Azure Functions - Best Practices - FUNCTIONS_WORKER_PROCESS_COUNT
MSFT Sources of Azure Functions Premium Plan Scale-Out Instances:
Azure Functions Hosting options Information
Azure Functions Premium Plan Instances Billing
AFAIK, FUNCTIONS_WORKER_PROCESS_COUNT limits the max no. of worker processes per Function host instance. These instances are kind of separate VMs where the FUNCTIONS_WORKER_PROCESS_COUNT limit is applied to each of them individually.
For example, If the FUNCTIONS_WORKER_PROCESS_COUNT is set to 10, it means 10 Individual Functions concurrently run by each host instance.
Multiple Workers means Multiple Process Ids of the Same Function App which is a logical collection of Functions.
One Worker Process can host all functions of one Function App where the Single Host has the default value as 1 to the FUNCTIONS_WORKER_PROCESS_COUNT and the Function Host means it is the Physical/Virtual Host where Function App runs as Windows/Linux Process.
Refer here for more information on mechanism of FUNCTIONS_WORKER_PROCESS_COUNT.
how it can affect costs.
As this Microsoft Azure Services Pricing Calculator Says, you'll be charged per instance when you scale-out.
When it comes to Cost Management, the incremental nature of the Scale-Out methodology is extremely beneficial.
Cost increases should be somewhat predictable because the components are identical.
Scaling out also allows you to respond more quickly to changes in demand.
In most cases, services can be quickly added or deleted to satisfy resource requirements. By just using (and paying for) the resources required at the time, this flexibility and speed effectively minimize spending.
Refer to this article for more information on cost management and the benefits of Scale-Up and Scale-out.
I am using Azure Functions on the App Service Plan. My understanding is for every new execution the Azure Function will create a new App Service, execute the function and then shut down the App Service. There would be nothing shared between the multiple App Services that are spawned due to multiple requests.
However when I do test my Function(which is a video processing one), for one request the time it takes is around 2-3 mins however for multiple simultaneous requests the time increases to 10-15 mins. My questions are whether my understanding above is correct? If not then what resource is shared amongst these App Services? How should I decide my scaling options(manual vs auto)?
"My understanding is for every new execution the Azure Function will create a new App Service" Nope it will not run new instance each time. Generally if there is no load on AF it will stop all instances.
Then if first request/event comes in it will start first instance. This is why we have ColdStart in Serverless. After that scale controller will measure your instance performance memory and CPU consumption and decide if it needs to scale but it wont be instant. So if lets say you sent N amount of requests to do smth with video they could go to same first instance and increase load. Then AF will scale, because of CPU spike but it wont help with old requests since they are handled at first instance. Keep in mind For non-HTTP triggers, new instances are allocated, at most, once every 30 seconds which means that your AF should have CPU spike for at least 30 second to add new instance https://learn.microsoft.com/en-us/azure/azure-functions/event-driven-scaling
I am not sure if Azure Functions are good option for video processing. Azure function should be used for quick stuff usually I would say not more than 30 sec. But there are some limitation of execution time depends how you run it https://learn.microsoft.com/en-us/azure/azure-functions/functions-premium-plan?tabs=portal
Not sure what type of video processing you doing but i would have a look into Azure Media Services
The other options as you mentioned is Batch jobs with low priority https://azure.microsoft.com/en-au/blog/announcing-public-preview-of-azure-batch-low-priority-vms/ it actually a good use case you have: Media processing and transcoding, rendering and so on
A small addition to Vova's answer: if you're running your Function in an App Service (also known as a Dedicated Plan), it will by default only scale instances within the possibilities of the App Service Plan you defined. This means that all of the instances of your Function App run on the same virtual machine. That is most probably the reason you're seeing increasing request times with more requests.
If you want your Functions to scale beyond the capabilities of that plan, you will need to manually scale or enable autoscaling for the App Service plan.
An App Service plan defines a set of compute resources for an app to run. These compute resources are analogous to the server farm in conventional hosting.
and
Using an App Service plan, you can manually scale out by adding more VM instances. You can also enable autoscale, though autoscale will be slower than the elastic scale of the Premium plan. [...] You can also scale up by choosing a different App Service plan.
If you run your Function App on Consumption Plan (the true serverless hosting plan option since it enables scaling to zero),
The Consumption plan scales automatically, even during periods of high load.
In case you need longer execution times than those available in Consumption Plan, but the App Service Plan doesn't seem to be the best hosting environment for your Functions there's also the Premium Plan.
The Azure Functions Elastic Premium plan is a dynamic scale hosting option for function apps.
Premium plan hosting provides the following benefits to your functions:
Avoid cold starts with perpetually warm instances
Virtual network connectivity.
Unlimited execution duration, with 60 minutes guaranteed.
Premium instance sizes: one core, two core, and four core instances.
More predictable pricing, compared with the Consumption plan.
High-density app allocation for plans with multiple function apps.
More info on all the different Azure Functions hosting options.
I have an azure function that reads jobs from a storage queue. It then executes these jobs and grabs more. I have been getting more jobs for it to run lately and noticed that the queue is building up.
What can I do from an Azure Perspective to get better performance out of this? Each job runs in its own little world so adding a new instance or adding threads or attaching to a "better" machine would all work fine.
Things come to mind with the information provided:
For more pure power: Host your Azure Function in a dedicated App Service plan instead of using the consumption plan. You can scale up (better hardware) or out (more hardware). Be aware that this could also be worse in theory. I would give it a try. Or try the "premium consumption plan" mentioned by Ken.
More parallelism: If your queue builds up even though you are not using most of your resources. Try playing with the configuration parameters batchSize and newBatchThreshold.
Changed execution logic: Depending where most of your time is spent during function execution, durable functions might help. Based on your comments you might also try to cache the external data using static or Azure Redis Cache.
Look at the most common performance considerations
Premium plan (Preview)
Azure Functions Premium plan provides customers the same features and scaling mechanism used on the Consumption plan (based on number of events) with enhanced performance and VNET access. Azure Functions Premium Functions plan is billed on a per second basis based on the number of vCPU-s and GB-s your premium functions consume.
In order to use the Azure Functions Premium Plan private preview your subscription needs to be added to an allowlist. Please apply for access via http://aka.ms/functionspremium.
More Info:
https://github.com/Azure/Azure-Functions/blob/master/functions-premium-plan/overview.md
I am using Azure Function app service plan to serve client requests. Reason for selecting Azure service plan is, requests are long-running and takes more than 10 minutes.
I am looking for implementing Azure architecture which will be cost-effective and perform better for a large number of requests.
Any suggestions on what Azure components I can use or what architecture I should follow.
More details and characteristics about the workload are really necessary to offer up any solid suggestions (e.g. is it memory, cpu intensive? Is it dependent on downstream resources etc). Depending on your workload Functions and\or App Services may not be a right fit.
At a high level consider if refactoring this 10 minute process is an option. Many times long running tasks are in actuality many smaller tasks that can be broken down so their individual execution times are reasonable and you can then make use of the scaling aspects of Serverless (Azure Functions). If this is the case but breaking it down is too complex to orchestrate consider using something like Durable Functions or Logic Apps to provide that orchestration for you.
Generally speaking if I have long running requests it typically means its async from a user perspective and latency isn't an issue so another option is to have an Http Trigger (API) on an Azure Function running on a consumption plan so it will scale as needed and that accepts the request and places it on a queue but the queue listener is on dedicated compute without time restrictions (e.g. Function on App Service Plan, Azure Container Instances, etc). Keep in mind you need to be careful about your queue length as you could get lots of requests in your queue but only limited resources to process them on your dedicated compute within an acceptable time frame.
At the end of the day though "cost effective" AND "performant" is often a tough ask (outside Serverless) and my suggestion is to refactor your workload if you can.
Azure Cloud Services have auto-scale based on CPU / Queue. We have a set of machines running API for uploading and processing files. Although we moved the processing part on Worker Role that scale depending on the queue size, the servers but also take care of the upload while responding to other operations like downloading.
Right now we're using more machines for the just in case scenario, but we want to build a way to scale and to be cost-efficient while having a great upload experience for our users.
What would your approach be for creating a way to detect the network usage across all machines from the same Cloud Service and auto-scale if necessary?
I would:
1) Create metrics that calculate the amount of time it takes to download/upload a file.
2) Aggregate the metrics in some persistence layer (we have plenty in Azure)
3) Create a service that looks those metrics
4) Check the thresholds
5) Use the Management Libraries for .NET to trigger scaling on the Cloud Service(s) affected.
This approach also scales with your solution. You can eventually separate the scaling part from the checking part and have them as two different services, communicate asynchronously.
We also have an old, open source now project that does some of that for you, so you don't have to reinvent the wheel. It's called WASABi. Be careful though as this is not maintained anymore but as I said, you can use it as inspiration.