I have currently a WebAPI which has a GET method that reads 10,000 rows from a SQL Database and process to create a JSON object. I use Azure App Service Plan to host this WebAPI.
My question is, is Azure Function App a suitable platform to host the business logic which the WebAPI currently does by considering the amount of data retrieved and the processing has to be done.
I think Azure function is a choice for you as it is designed to architect serverless solutions. And in the Azure function document there is similar scenario as yours.
Also, just like #ThiagoCustodio mentioned in the comment, you still need to consider the function app timeout duration. Here is a reference of timeouts regarding different hosting plan.
Reference:
Optimize the performance and reliability of Azure Functions
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.
Can I deploy one Azure time trigger function from one repo to multiple App Services?
Example:
Currently I have a repo with one Azure function in it (name Function1, runs every few mins).
I have 5 customers, I have a database for each customer and therefore I have 5 connection strings. Each customer requires me to host the function in isolated environment independent from the other customers.
The function "Function1" does the same logic for each of my customers. It just accesses a different database for each using the different connection string.
Therefore, I created 5 App Services: Function1-Customer1, Function1-Customer2, ... to satisfy the "independent environment requirement".
Each App Service has the unique db connection string assigned in the App Settings.
I tried to deploy the "Function1" to all these 5 App Services. However, when then going to see the Log Stream for any of the App Services it seems that only one instance of that function is running, depending on which App Service deployed last.
So for example, if Function1-Customer1 deployed last and I go to Function1-Customer2 or Function1-Customer3 to see the Log Streams, both outputs a conn string of Function1-Customer1. If Function1-Customer2 deployed last then I would see its conn string in all other App Services.
Is it possible to deploy the Function1 to serve all these 5 App Services? Or do I need a different architecture here?
The functions coordinate by obtaining leases in the underlying blob storage. If two function apps end up fighting over the same lease, they will block each other even though they are supposed to do different things. You can explore this by looking at the blobs in the underlying storage account an check the "lease" status.
Based on our discussion in the comments, I would recommend to use a dedicated storage account for each function app. I would not recommend AzureFunctionsWebHost__hostid or similar solutions, since it adds more complexity.
For each trigger Azure function manages it's own queue in Azure Queue Storage. You can use single function app and trigger 5 different tasks for each customer or you can create separate Azure storage account for each function app.
How does a Azure function differ from a ASP.NET Core Worker Service?
Does both of these cover the same use cases?
How do I decide which one to use?
Update:
Azure function is designed for azure. So when you use azure, or other azure services which are integrated with azure function, you should consider azure function, which could simplify your code and logic by the built-in features of azure function. But it will also have charges for azure function. And yes, if you don't use azure, just use asp.net core worker services.
Azure function are totally different from ASP.NET Core Worker Service.
The benefit of Azure function is that it supports a lot of triggers like azure blob trigger / azure event hub trigger, and is integrated with other azure services.
With these built-in features, it's easy to create a proper azure function to complete a proper task. For example, if you upload an image to azure blob storage, and then want to resize the image, you can easily create a blob trigger azure function with less code.
Worker services are the perfect use case for any background processing. And if you want to operation some azure services like azure blob / azure event hub etc. you may achieve this but need to do a lot of work.
At last, it depends on your use case to choose which one should be used, and select the simple / efficient one.
I think the answer Fred was looking for is, why would someone use Azure functions over Asp.net Core hosted service? And the answer isn't only because you have Azure account so everything is easy and integrated. It depends. I.e Traffic, cost, expertise, etc.
Actually, there are guidelines set by Microsoft when to use an Azure Functions versus let's say over a IHosted service running in a linux container hosted in AKS for example. and I'll post the link, but it's basically if your workload is mission critical or not. If you want the best performance, lowest cost, reliability a hosted dotnet core service running in Linux container would be an excellent alternative.
Here is the mission critical guidelines from Microsoft, hope this helps!
Design recommendations
Azure Functions:
Consider Azure Functions for simple business process scenarios which don't have the same stringent business requirements as business-critical system flows.
Low-critical scenarios can also be hosted as separate containers within AKS to drive consistency, provided affinity and anti-affinity requirements are fully considered when collocating containers on nodes.
Excerpt taken from here:
https://learn.microsoft.com/en-us/azure/architecture/framework/mission-critical/mission-critical-application-platform
Following is the proposed transition in our application:
Web Application is deployed in on-premises IIS (Web Server 1).
Web Application has one functionality (for example, Generate Invoice for selected customer).
For each new request of Generate Invoice, the web application is writing message to the Azure Service Bus Queue.
Azure function gets triggered for each new message in Azure Service Bus Queue.
Azure function triggers Web API (deployed on-premises).
Web API generates Invoice for the customer and stores in the local file storage.
As of now, we have everything setup on-premises, and instead of Service Bus and Azure function, we directly consume Web API. With this type of infrastructure in place, we are currently logging all events in an MongoDB collection, and providing single consolidated view to the user. So they can identify what happened to the Generate Invoice request, and at which level and with which error it got failed (in case of failures).
With the new proposed architecture, we are in process of identifying ways for logging and tracing here, and display consolidated view to the users.
The only option, I can think of is to log all events in Azure Cosmos DB from everywhere (i.e., Website, Service bus, function, Web API), and then provide consolidated view.
Can anyone suggest if the suggested approach looks OK? Or if anyone has some better solution?
Application Insights monitors the availability, performance, and usage of your web applications whether they're hosted in the cloud or on-premises. It leverages the powerful data analysis platform in Azure Monitor to provide you with deep insights into your application's operations and diagnose errors without waiting for a user to report them.
Workbooks combine data visualizations, Analytics queries, and text into interactive documents. You can use workbooks to group together common usage information, consolidate information from a particular incident, or report back to your team on your application's usage.
For more details, you could refer to this article.
Is there any integration between CosmosDB and Api Apps? I'm kinda new in Azure and I don't really understand which is the best approach.
My problem is that I am working on an IoT Project which gets data from the IoT Hub, passes it to a Function that sends it to the CosmosDB which then would need to be consumed by a Frontend. A pretty standard case.
I would usually create a backend to place between the database and the frontend but I really can't understand which is the best way to do it in Azure. Should I use the Api Apps or the integrated SQL Apis that are provided with CosmosDB? Are the Api Apps comparable to "containers" for my backend or do they have any other use other than keeping my code in a cloud machine?
Thanks a lot in advance!
You can't (well, shouldn't) have your frontend to directly call the database so you need a middle layer of some sort.
Creating an API could be one of the ways you go about it but based on your use-case, I would go with an HTTP Trigger Azure Function which would be the API that exposes the data.
You can then use the Cosmos DB Input Binding to retrieve the object you want to return and simply return the JSON of it.