We are going to host our ASP.Net web site on Azure server. I am not quite familiar with Azure. I need to create some kind of scheduler which will send request to google API once a week and save response data to DB. I read some articles about Worker Role. Is it suitable for this? How it should be deployed to the Azure server? Any other solutions?
You could certainly make use of Worker Role for that purpose however I would not recommend going down that route as you are only going to use the functionality once a week. Or in other words you would be under utilizing the resources. Do take a look at Windows Azure Mobile Service Scheduler: http://www.windowsazure.com/en-us/develop/mobile/tutorials/schedule-backend-tasks/. Other alternative would be use a 3rd party service like Aditi Scheduler: http://www.aditicloud.com/. There's also a website which also allows you to do the same functionality (I'm sorry I forgot the name of that site :)).
If you're still keen on doing it through Windows Azure Worker Role, I wrote a blog post about the same which you may find useful: http://gauravmantri.com/2013/01/23/building-a-simple-task-scheduler-in-windows-azure/.
Related
I am looking at possibly running some of our business on Azure.
I am trying to pick the services that would work best for my company, but I am getting mixed signals.
Because I am starting a new system, I want to pick the offerings that are not "legacy" (aka "current"). But there seems to be no way straight forward way to know that.
For example, this page of the Microsoft Documentation says
Cloud Services is similar to Service Fabric in degree of control versus ease of use, but it’s now a legacy service and Service Fabric is recommended for new development.
This page clearly states that Cloud Services is "legacy". However, you would never know this by going to the Cloud Services overview page. It has great marketing material that sells Cloud Services as a great option. But if I picked it, then I would be starting out on a platform that is in a legacy status.
Now I know that about Cloud Services vs Service Fabric. But there are tons offerings on Azure. I am trying to research them one by one to find out which ones are the most recent incarnation, but I feel like I am wasting my time.
Another example is storage. Lucky for me an Azure MVP answered my question on this one. Apparently, there is "older storage account" based disks and "managed" disks. Turns out managed disks are the new, easy way to do things. The storage account is harder. Still available, but not really what a new user should be picking. But again, this is very hard to find out unless someone who has been working with this stuff for a long time tells you.
I was about to start in on App Services and Web Apps, but I thought I would ask first to see if I am doing research that is already done and posted out there.
Is there somewhere that shows the current list of Azure services that you should look at if you are starting a new project?
I asked the similar question almost a year ago, and I even spoke with Azure Support Team after that. At that time, Microsoft did not officially state Cloud Service is legacy.
Does Azure App Service/Web App replace Azure Cloud Service?
We have been hosting our enterprise applications in Cloud Service since 2013, and a couple of them are in App Service. Here is my thought -
4 years ago we only have Cloud Service - Web Role and Worker Role,and App Service (formally named as Web App) is not fully ready for enterprise applications yet. Since App Service came up, Microsoft heavily promote App Service compare to Cloud Service. In addition, what I notice is Cloud Service did not get new features like App Service.
Service Fabric is quite new, and it doesn't have all the belts and whistles like App Service, so we might have to wait a bit for enterprise applications.
Only advantage of Cloud Service is you can remote desktop to a role instance, after the application is deployed.
If I host a new application in Azure today, I'll definitely use App Service.
Microsoft has published a list of Azure reference architectures. It was last updated in November 2016. You can browse it here, and there is some guidance given. But for example, you mentioned using Service Fabric (which is a great way to go for a robust app that really needs to scale), but Service Fabric isn't mentioned in the aforementioned resource.
I spend a lot of time running down Azure resources in relation to web applications (not to be confused with App Service Web Apps), and I have not found a definitive source of the type of info you're looking for personally.
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 noticed when accessing windows mobile service I can schedule tasks to perform at certain times. I also noticed that the script to perform these tasks is only javascript? Is there a way I can use some server side code to perform a mobile service?
I want to be able to connect to an API. Check for a specific update. If that update is present send an email to myself.
Unfortunately this API suffers from the same-origin policy and doesn't offer a solution like JSONP. Therefore I will need to handle this API access server side.
Currently you can only use JavaScript, but support for other languages (like C#) is planned.
I was interested in Widows Azure Mobile Services because of the Scheduler service, as a simpler alternative to jobs running in Worker Roles with Quartz and other alternatives, but I felt the same difficulty you describe in having to work in a JS only environment, which is a problem in my scenario.
Are you aware of Windows Azure Web Site Web Jobs (here and here)? You can configure continuous or scheduled jobs developed in many script languages as well as in .Net.
We moved many smaller tasks from under-utilized and more complex Worker Roles to Web Jobs as simple .Net console apps. Via the Web Jobs SDK you also get a good monitoring environment.
I just moved some of are web api from IIS web role to a worker role in Windows Azure and that is working way betting. What I want to know is how much better so, and before we using New Relic to monitor the web server. I have the agent installed on the worker roles but not getting any of the great analytics.
(What I followed to make this work)
So I was hoping someone could help me get some basic stats on how well my self-hosted web server is performing into new relic. I looking for throughput, response time, and log errors.
I found something that seems to make me think that I could do it but I am not familiar with owin.
If anyone has some ideas on how to get this work that would great!
Edit:
What I am looking for is if someone can help me use the newrelic api ( RecordMetric(), RecordResponseTimeMetric(), IncrementCounter(), etc.) and hook it up in the owin pipeline to record throughput, response time, and log errors?
The New Relic .NET agent gathers most transaction-related metrics within the context of the IIS pipeline. The agent can get some basic metrics for standalone services like Worker Roles (WaWorkerHost.exe). Without any special setup, you can monitor calls per minute, RAM/CPU utilization, database calls and external requests. Beyond this, you'll want to use the .NET agent API:
https://newrelic.com/docs/dotnet/the-net-agent-api
Namely RecordMetric(), RecordResponseTimeMetric() and IncrementCounter() are available for Azure Worker Roles and other non-IIS applications. Other methods in the API require proper HttpContext instances.
We are thinking of using Windows Azure for simulation. ~100 VM nodes each working on it's problem set and reporting back the result to a Master node.
I have created VM instances from the web UI. In order for this to work, we would need to use Azure API to bring servers up and shut them down once they are done.
Does anyone have any experience with something like this? I am looking for advise, gotchas etc.
thanks.
You sure can do it and I have helped other to make it happen on hundreds on nodes. Take a look at Windows Azure Rest API to configure your role as described here. While others may have other idea, I think the general steps would be as below:
Create a master machine or a webrole to manage your roles using REST API
Create a worker role instance and use it to clone multiple instances as if needed
Use REST API to start and shutdown worker role along with update the instance count when in need
Use Azure Boot Strapper to bootstrap the VM depend on your requirement
Azure REST based Service Management API can work from a web app or a standalone app, so you can also have a web role to make it happen from anywhere in world. This way you don't need any on premise components at all as it will be totally cloud solution. If you need any help on creating web role I sure can help.
You can provision Virtual Machines using Service Management REST API (there's also a managed API on NuGet).
But in your case you might want to consider using Cloud Services (PaaS). With Cloud Services you simply build your application, you package it and deploy it. Then using the portal or the management API you can simply configure the number of instances. There is even a command line tool (csmanage.exe) which allows you to to change the number of instances through the service configuration.