I am trying to build an Azure Durable function to orchestrate the execution sequences between multiple azure functions. Sometimes few of those functions are required to be executed parallel, sometimes in sequence. Its all based on some JSON configuration files.
But I am expecting my durable function being called by more than 1000 consumers and this every minute there is a probability of 1000 hits to the durable functions end point. Since internally durable function uses queues and tables, individual calls from durable functions will be organized, but what are the solutions available in azure to manage the situation of large number of hits in this durable function's API endpoint.
You can go through this load balancing solution documentation in Azure to decide on best load balancing solution to use in your case.
Given if it is a HTTP based application and based on the service provided, you can take a look at
Azure FrontDoor: It is a modern cloud CDN solution which provides fast, reliable, and secure access between your users and your applications’ static and dynamic web content across the globe. You can enable caching on the frontdoor to reduce the calls made to your backend. You can also secure your application with WAF.
Azure Application Gateway: It is a regional load balancer for a web application, where you can take advantage of features like WAF, auto-scaling, URL based routing etc.
Based on your requirements you can use both application gateway and front door together, more information can be found here.
Related
I am debating what is the more "correct" / better performance solution to implementing a REST API on Azure that has a basic CRUD to a database:
Create a Fast API app and deploy it simply on an Azure App Service
Create an Azure Function App that every endpoint is represented by an Azure Http trigger function (inside of the azure function app) - the code in the function will be the basic CRUD functionality of the endpoint written in python (has nothing to do with fast api - basically only uses the pure code that would be inside a FastAPI route).
Both eventually would be wrapped with Azure API Manager.
What solution will have better response time?
Will server-less be more resilient?
Thanks
If the functions use the python runtime, then FastAPI is a very popular alternative.
I personally found the migration of Azure Functions to a FastAPI App Service to be very smooth and hassle-free.
Differences between the above two:
Function Independent Changes: Primarily we need to import FastAPI and Status, CORS Middleware in the include statements to avoid CORS issues.
In the Azure functions, CORS will be enabled through the portal.
For getting the more information about the differences like Function dependent changes, Return Statements, adding more than one function/endpoint, please visit this article.
FastAPI ranks among the highest-performing Python web frameworks for building APIs out there and it's being used more and more day by day.
Not only in terms of the number of queries handled per second, but also the speed of the development and its built-in data validation makes an ideal for the backend side.
A few other aspects which you need to think about like scalability, cost and ease of development.
If you use Fastapi on an app service, you will need to configure the
scaling rules yourself. An azure function on consumption or premium
plans will scale automatically.
Fastapi on an app service will cost money even if you are not
using it. But an azure function on consumption plan will cost only
if you use it and you get 1 million executions free every month so
the cost is basically nothing if your execution count is < 1M.
Since FastAPI is an API framework, it comes in built will correct
responses in case of errors and you just handle whatever you need to.
For Azure function you will need to code pretty much everything.
I am looking for some design guidance in using Azure APIM as a forward proxy between backend services (such as function apps or logic apps) and external clients.
We have a function app that processes invoice requests (for an order previously placed) from a mainframe system, does some transformations and sends them to an external party via HTTP. I have two options with the sending process.
Store external HTTP endpoint as an app setting in function app and let function app send the
transformed message directly to external party.
Send the transformed message to Azure APIM with the external HTTP endpoint set as the backend service (using set-backend-service APIM policy) and let APIM forward it to external party.
Now, are there are any real benefits with the second approach if the requirement is only to forward requests to external party from a security or operational standpoint? There are no requirements to enrich the outgoing message (add or remove headers, modify message body etc).
Personally, all I see is an extra hop with the second approach. But some of my teammates seem to think the second approach can offer some benefits in the way of analytics. There are some metrics available under APIM --> Analytics tab that lets you see the number of successful, failed requests etc. But I think this information is also available to Application Insights tied to the function app.
Just interested to see some insights around this so we can make an informed decision.
I guess using Azure API Management would be an over-engineering in your case, assuming the Azure Function is only going to be the caller of the Azure API Management instance.
Even though Azure API management provides analytics, url-rewrites, transformations, analytics etc - it makes more sense when you use it to govern the API. Ask yourself a question on, how many of the Azure API management functionalities are going to be leveraged fully in your case.
Remember Azure API management by design is an API governance tool where you can perform throttling, monetizing your API by giving access to it to different 3rd party with segregated subscription keys. In my opinion, Azure API management comes into the scene where you need to distribute some API to 3rd party applications, which clearly not in your case.
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.
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.
I'm trying to figure out a solution for recurring data aggregation of several thousand remote XML and JSON data files, by using Azure queues and WebJobs to fetch the data.
Basically, an input endpoint URL of some sort would be called (with a data URL as parameter) on an Azure website/app. It should trigger a WebJobs background job (or can it continuously running and checking the queue periodically for new work), fetch the data URL and then callback an external endpoint URL on completion.
Now the main concern is the volume and its performance/scaling/pricing overhead. There will be around 10,000 URLs to be fetched every 10-60 minutes (most URLs will be fetched once every 60 minutes). With regards to this scenario of recurring high-volume background jobs, I have a couple of questions:
Is Azure WebJobs (or Workers?) the right option for background processing at this volume, and be able to scale accordingly?
For this sort of volume, which Azure website tier will be most suitable (comparison at http://azure.microsoft.com/en-us/pricing/details/app-service/)? Or would only a Cloud or VM(s) work at this scale?
Any suggestions or tips are appreciated.
Yes, Azure WebJobs is an ideal solution to this. Azure WebJobs will scale with your Web App (formerly Websites). So, if you increase your web app instances, you will also increase your web job instances. There are ways to prevent this but that's the default behavior. You could also setup autoscale to automatically scale your web app based on CPU or other performance rules you specify.
It is also possible to scale your web job independently of your web front end (WFE) by deploying the web job to a web app separate from the web app where your WFE is deployed. This has the benefit of not taking up machine resources (CPU, RAM) that your WFE is using while giving you flexibility to scale your web job instances to the appropriate level. Not saying this is what you should do. You will have to do some load testing to determine if this strategy is right (or necessary) for your situation.
You should consider at least the Basic tier for your web app. That would allow you to scale out to 3 instances if you needed to and also removes the CPU and Network I/O limits that the Free and Shared plans have.
As for the queue, I would definitely suggest using the WebJobs SDK and let the JobHost (from the SDK) invoke your web job function for you instead of polling the queue. This is a really slick solution and frees you from having to write the infrastructure code to retrieve messages from the queue, manage message visibility, delete the message, etc. For a working example of this and a quick start on building your web job like this, take a look at the sample code the Azure WebJobs SDK Queues template punches out for you.