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
Related
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.
My question is about make API request from azure web jobs.
I have created azure Apps service for my web application (MVC C#).I have one API that need to run once in a day.I found one component in azure namely Azure Job which is paid one.Later I get to know about web jobs in my same Apps Services which not need to pay anything more, but I am not able to find anything that connects Web Jobs with API calls.Everywhere its mentioned about '.exe' files only.
I think that the first thing is that you could refer to this document to learn what is webjob.
WebJobs is a feature of Azure App Service that enables you to run a program or script in the same context as a web app, API app, or mobile app. There is no additional cost to use WebJobs.
As Ivan yang mentioend that you could create a console application or script and add call rest API code in it.
Note : If your app runs continuous or scheduled WebJobs, enable Always On to ensure that the WebJobs run reliably. This feature is available only in the Basic, Standard, and Premium pricing tiers.
I recommand that you also could use the Azure function to do that.
We have an application which is an Asp MVC application which communicates via WCF to a middle tier application. We will be rewriting this and want to target Azure
It's split into 3 tiers, web, business, database, which are all on separate machines, as some of the business processes can take a few seconds. When the web calls the middle tier it must wait for a response before returning to the user, i.e. something like a message queue isn't appropriate here
I'm thinking for the new architecture we have
Client: AngularJS
Web: Probably Asp MVC controllers in a Web App
Middle tier: ?
Database: Azure SQL Database
The middle tier is where it gets confusing, what is this in terms of Web Apps and how does it communicate with the web? I think we'd prefer a RPC approach rather than REST based if possible. We just want to send serialized classes back and forth
What about scalability? We're presently assuming that the web will need to be stateless
Since Azure Web Apps is a platform that builds on top of IIS, you can run an IIS-hosted WCF-service on Web Apps just fine.
As for scalability, Azure App Service allows you to scale horizontally manually or automatically.
If the Web and Middle tier share scaling requirements, you can place both on the same App Service Plan. Then they share the instances and scale simultaneously. If however their scaling requirements are quite different, I recommend you put them in their own App Service Plans. Then one's scaling doesn't affect the other.
I'm currently developing a SOA based architecture in Azure, using disparate Web API services (they'd probably qualify as Microservices, but I'm hesitant to use the term).
I have a service which is triggered by the Azure Scheduler. It does some "stuff" and then needs to call another Web API (via HttpClient) service to trigger something else. To do this, I need to know the URI of the 2nd service. When running locally, this is fine, as it is something like
POST http://localhost:1234/2ndService/api/action
However, when I deploy to Azure (using Internal Only as the access level), it gets an obfuscated URI, such as http://microsoft-apiapp8cf3d453-39d8-4b3b-ad00-e9d8008a9b58, which I obviously can't guess at deploy time.
Any ideas on how to solve this problem? Or have I made a fundamental error here?
Instead of relying on public http endpoints, have you considered passing messages via queues in Azure Table Services? It's very simple to do and is going to be more robust since you can take advantage of built-in features like guaranteed message delivery.
The overall idea is that Service A does some "stuff" then puts a message on queue ONE. Service B continuously reads from queue ONE until it picks up a new message from Service A (or any other service for that matter) and then does its "STUFF". You can continue to chain calls like this to other services that need to be notified.
If you want a more elegant solution you can look at using Service Bus Topics but the concept is basically the same.
Also, since you mentioned that your architecture is much like microservices, you can check out the new Service Fabric which is designed for your scenario.
In case of Azure Web Apps, you may always see such properties going to the web app dashboard, then properties. When deploying from the Visual Studio, you can set the URL as you want - just checked it, and it works fine.
Not very clear what technology do you use - is it IaaS VM? Is it Web Apps?
From my standpoint, each service should be deployed as a separate Web App (or API App, if you want). Each Web App has defined its own name as in yourwebapp.azurewebsites.net, so once you have provisioned the Web App no 1 in Azure, you know its address so you will call it from the Web App no 2.
In all the cases, you should have fully qualified domain names, and not local/internal ones.
I have an MVC front end application (relatively small) with its own DAL implementation using repository pattern. I am thinking of moving the DAL in its own WebAPI project to maintain cleaner separation. The MVC app is hosted in Azure using a cloud service (web role). The WebAPI will only be used by the front end application and would not be exposed to any other external application for now, but even then i would still want it to be hosted as a separate app/web/worker role rather than keeping the DAL in same project.
Would it be a good idea to:
1) Host the WebAPI project within the same Cloud Service as a Web/Worker role or should I create a new website/cloud service for hosting it? Using the same cloud service is preferred keeping the cost factor and n/w latency issues in mind.
2) If I host in same cloud service, what is more advisable to use for web api project - web or worker role?
3) Somewhere i read that I should make use of Service Bus in Azure for interaction between MVC frontend and WebAPI backend. Is this the suggested way of doing it or is there any simpler way of getting it done?
I would suggest you to use the same cloud service. The reason being complexity and failure scenarios, when you split your app into multiple cloud services the problem comes when you are updating them service from your source control
You will need to do two deployments and make sure they are in sync etc.
I would keep the service runtime simple in one cloud service.
Again it is preference and comfort, if you really want to separate them at code level and know they will work fine. The two cloud services should be OK.
From experience, refactoring decision like these add a lot of work in the future. Positive or negative depends on your understand of the problem and the image of the bigger picture you have in your head that cannot be put on paper :).
Happy to Help, Yours Truly -CB