I have a service, (.net core 3.1), that receives messages, a lot of them, and stores them in a DB.
The original is baked into an API and deployed as an App Service.
The App Service works fine. Great for the API and the Web but I'm uncertain whether it's the best choice for the service which I now intend to separate from the App Service. It's more or less background worker that just collects data and saves it.
I would like to know if there are any other more suitable Azure products other than App Service or should I go with another App Service?
It seems your use case basically fits to serverless scenario. All your messages processing can be handled by Azure Function.
https://learn.microsoft.com/en-us/dotnet/architecture/serverless/serverless-business-scenarios
https://learn.microsoft.com/en-us/dotnet/architecture/serverless/serverless-architecture
I have a web api(.netcore) which I have hosted in Azure under an app service.
I have another app related to the above api(in the same resource group) which need to be triggered every few minutes.
My confusion is what is the best practise?
1) Write a webjob app(.net framework) for the second app.
2) Write the second app as an api and write a console app to call the api. Then call the console app from the webjobs in Azure. But that would mean a second app service in the same resource group(for second API).
Is there any pricing difference between the two?
Is there any advantage of one over the other?
Is there any better way?
Update
I have gone with the second option.
Is there any advantage if I go with the below(cost and code vice).So in the same app service there will be a wep app, a webjob to trigger the api and another webjob to read message from queue do the processing.
There are a few options for writing a service that is triggered on a timer:
WebJobs - These are essentially console apps that run behind the scenes to do related jobs that users of your API don't need to wait on (photo processing is a common example) or need to be run on a schedule, like your use case.
Azure Functions - Functions are similar to WebJobs, but make it easier to scale and abstract away the necessity of coding up connections to a lot of other services. They also can have billing advantages if you are creating an App Service just to run them.
Azure Logic Apps - I think you want either WebJobs or Functions, but Logic Apps can also run a job on a schedule. In this case, you are designing your workflow either in JSON file or more likely in a GUI. If your job doesn't require much custom code, using a Logic App means that development time is reduced and you have one less piece of custom code to maintain.
For pricing:
Both Webjobs and Functions can be attached to the same App Service account as your API as long as you have sufficient resources there to handle the additional load. So no additional costs there.
You could pay for a separate App Service account for the Webjob if you want, but usually they are kept on the same App Service account as the API.
Functions apps can run on a special type of App Service account that has a consumption plan. What that means that instead of a monthly fee, you pay for the resources that you actually use.
Logic Apps aren't connected to App Services, and have consumption based billing similar to Functions.
I have a long running console application, using while(true)... structure
It implemented by using Net Core
What type of Azure App Service I should create to host that application ?
Decision tree for Azure compute services
Azure offers a number of ways to host your application code. The term compute refers to the hosting model for the computing resources that your application runs on. The following flowchart will help you to choose a compute service for your application. The flowchart guides you through a set of key decision criteria to reach a recommendation.
Treat this flowchart as a starting point. Every application has unique requirements, so use the recommendation as a starting point. Then perform a more detailed evaluation, looking at aspects such as:
Feature set
Service limits
Cost
SLA
Regional availability
Developer ecosystem and team skills
Compute comparison tables
I recommend reading this guide afterwards
Criteria for choosing an Azure compute service
Another great entry point for developers concerned with a similar question
.NET application architecture
You have to use "Azure App Service as a WebJob"
To deploy the .NET Core console application to an Azure App Service Web App Web Job access the Azure portal and navigate to the Azure App Service where you will host the WebJob.
Clicking on the Add button renders the blade
Once the WebJob is successfuly uploaded, it will render in the WebJob blade. Click on it and you will see the Run button. As this WebJob is a manually triggered job, you must click on the Run button in order for the job logic within the .NET Core console application to run.
After starting the .NET Core WebJob, click on the Logs link and a new browser tab is opened and you can see the most current state of the WebJob
I've been reading a few tutorials now on deploying Web Apps and API Apps to Azure. However, I am still a little unsure as to why you would use one over another.
I can create a new .NET solution with API controllers and deploy this as a Web App, so why would I specifically require an API App? Are these optimized specifically for ASP.NET Web API, where as Web Apps are for delivering HTML?
Updating the answer to current state of Azure,
App Services now replaces all Mobile, Api and Web Apps flavors as a single app framework with all the functionality rolled over to make things more accessible across application types. Currently all of Web, Mobile and Api Apps are collectively called App Services. We still offer customer to be able to create a Mobile App and a Web App in the gallery but that is basically resolve into an App Service App.
https://azure.microsoft.com/en-us/documentation/articles/app-service-api-apps-why-best-platform/
Features for Mobile work for Web App as well such as Easy Tables and Easy API. And features for API apps like API Cors and API definitions now work on web apps as well. A customer can host a single web app to act as any mobile service or an api with all the features offered through the app services.
We also have a new service in preview particularly targeting API Apps by offering a management experience for your APIs, Basically you can control the generate try API pages, gather execution analytics, throttle and much more. Check out the feature blog to learn more about the Azure API Management Features. And yes you can host the APIs as a App Service App and hook things up with API Management.
https://azure.microsoft.com/en-us/documentation/articles/api-management-get-started/
There was a point in time when there were differences between the different app service types, but that is no longer true. The documentation now states:
The only difference between the three app types (API, web, mobile) is the name and icon used for them in the Azure portal.
So it no longer matters which app service type you choose to deploy to (unless you care what the icon looks like).
UPDATE
Function apps are now the exception. Creating a function app changes the user interface in the portal. The underlying web app, however, is no different. Setting an app setting named FUNCTIONS_EXTENSION_VERSION = ~1 turns any web app into a function app (minus the user interface in the portal).
There are many minor difference between Web API and API Apps, but the very notable and key differences are
Native Swagger implementation - When you create API App in Visual studio, swagger reference comes by default. Swagger provide very developer friendly features for API consumers to Interact with your API thru Swagger UI. Also Swagger based API's provides client SDK generation (both .Net based client and Javascript based client) which makes easy to call API's just like regular method call.
Note: Swagger implementation on regular Web API is possible manually.
Ability to publish your API Apps into Azure Market Place. Azure Market Place is the public repository for all API Apps that can be consumed freely or by charge.
this 15 minute video from Channel 9 gives an excellent overview about Api Apps.
To supplement Greg's answer, Here's an even more recent article describing the differences.
To sum up:
"The key features of API Apps – authentication, CORS and API metadata – have moved directly into App Service. With this change, the features are available across Web, Mobile and API Apps. In fact, all three share the same Microsoft.Web/sites resource type in Resource Manager."
And here's another important note:
"If your API is already deployed as a Web App or Mobile App, you do not have to redeploy your app to take advantage of the new features."
This can depend on what you are trying to do, but you would use a Web API when you are creating a service. ASP.Net Web API is a framework for building HTTP services that can be consumed by a broad range of clients. This allows you to build it not only for a web app, but have it open to connect to Android apps, IOS apps, web apps, Windows 8 apps, WPF apps etc..
So if you need a Web Service but you don't need SOAP then you can use Web API.
Here my comments:
API app:
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Web APP: An application deployed with multiple functionallity, for example
a catalog for create, update and delete customers or to create a complete ERP.
Function APP: Is very similar to API app,
Used for specific functionallity. Triggering that functionality from an URL.
Can be used to use with GET, POST, PUT, DELETE.
Can receive parameters at BODY (Json).
Response with valid status code (fail, sucess.)
Actually you can deploy your aspnet webapi on Azure WebApp and a self host on Worker Roles.
On WebApp (former Azure websites), it will be deployed on IIS, so you can take advantage of IIS features.
I'm curious to know if this is possible, and if so, is it a good or bad idea?
We are developing an Azure application that is largely centered around worker roles that receive their work on a CloudQueue, and put the results in a CloudBlob, that the client then downloads. The web interface itself is a dead-simple ASP.NET MVC site that throws jobs in the CloudQueue, and builds URLs to download CloudBlobs.
Currently we accomplish this by having a Azure Cloud Project in our solution, which has a Web Role with the UI, and Worker Roles with the actual work.
Could we use Azure Websites to publish and host the UI, which calls back to our Worker Roles? The Azure DLLs are just regular old .NET libraries, I'm assuming Azure Websites won't have a problem with them. So, when we want to update the UI, we just publish with Visual Studio. And when we want to update the Worker Role - which is 300MB+ and has a bunch of nasty dependencies like Crystal Reports - we can build the cloud bundle and update the Cloud Service through the Azure management portal.
This seems to me like doing this would make it easier to update the UI. I think it would also be cheaper to host it, as we won't have to buy a bunch of instances for the Web Role.
If your question is "Could we use Windows Azure Websites*", based on your application architecture, you sure can use Azure Website to deploy your front end and configure all the networking connection properly so you can continue access other Azure Storage services. As you are using mostly Blob and Queue, you can continue use HTTP/HTTPS settings in the Azure websites. You can keep worker role by as it is however if it is very complex to deploy, using Windows Azure VM may be another direction to go.
I could say website deployment could be easier if your web app does not have something complex to configure in web server as websites may not be able to match web server level configuration compare to webrole and Azure VM. Answering "Easier and cheap" could be very subjective as this is all depend on load and distribution so you would have to try and evaluate it.