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.
Related
We have completed our ALZ design and are migrating our existing resources to the new subscriptions.
Also, we have deployed two small utilities AzGovViz and AzNamingTool in our new ALZ that the Cloud Operations team will access. I foresee additional 3rd party tools to be added and/or developed in-house.
Let's call them operational tools for the context of this question:
I have some questions about the recommended design for deploying these operational tools that are not LOB applications:
Does it make sense to reuse the same app registration or is it better to create one per tool? Every tool will have the same permissions and will be accessed by the same people. Currently, I have one App registration for bot utilities and it works. I am aware that app registrations do not have a cost but I am wondering what are the best practices or if there is a use case where an app registration is used by multiple apps.
About App service plan, we are using the free plan that has an app limit (no app plan limit) for up to 60 minutes. From the cost perspective, it seems it does not matter if each app has its own app service plan or if they share one. Would you create one shared app service plan to be used by all the operational tools?
What is the difference between azure API-apps,logic-apps,web-apps and azure functions? And what difference does it make for developer?
Logic Apps:
Logic Apps provide a way to simplify and implement scalable integrations and workflows in the cloud. It provides a visual designer to model and automate your process as a series of steps known as a workflow. There are many connectors across the cloud and on-premises to quickly integrate across services and protocols. A logic app begins with a trigger (like 'When an account is added to Dynamics CRM') and after firing can begin many combinations actions, conversions, and condition logic.
Api Apps:
API apps in Azure App Service offer features that make it easier to develop, host, and consume APIs in the cloud and on-premises. With API apps you get enterprise grade security, simple access control, hybrid connectivity, automatic SDK generation, and seamless integration with Logic Apps.
Web Apps:
App Service Web Apps is a fully managed compute platform that is optimized for hosting websites and web applications. This platform-as-a-service (PaaS) offering of Microsoft Azure lets you focus on your business logic while Azure takes care of the infrastructure to run and scale your apps.
Functions:
Azure Functions is a solution for easily running small pieces of code, or "functions," in the cloud. You can write just the code you need for the problem at hand, without worrying about a whole application or the infrastructure to run it. Functions can make development even more productive, and you can use your development language of choice, such as C#, F#, Node.js, Python or PHP. Pay only for the time your code runs and trust Azure to scale as needed. Azure Functions lets you develop serverless applications on Microsoft Azure.
Api apps and Web apps are pretty much the same deal. Logic Apps and Functions are the same in a sense that they allow you to do something as a response to event or on a schedule, but Functions are a way to run code (or existing app) and Logic Apps are more like a workflow constructor, where you take existing actions and chain them (so no coding, or almost no)
ps. You can easily find documentation for those online to get a broader understanding
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
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.
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.