I have a web application that was being developed using Web Roles in Azure. It is a relatively complex application in which clients communicate with each other via the web server. Client to server communication is via SignalR and within server instances Web Api is used.
It was critical that it was tested against multiple instances of web roles since the all of plumbing needed to potentially communicate across the various instances of web roles.
This was easy to do in web roles since in Visual Studio's project properties you would simply up the instance count and the Azure Compute Emulator would open a bunch of instances for you.
After attending a recent Microsoft technical briefing, it was suggested that web roles were being superseded by Web Apps in Azure App Service. Indeed on the surface these appeared to be a better fit to my problem and I have been investigating this as an architecture.
The problem I have found is how to simulate multiple instances? Web Apps in development spin up in a single IIS express instance and thus have the same IP address on my development computer. Web Roles spin up in difference instances and all have different IP addresses which makes testing easy. From what I understand on production, web apps, if configured to have multiple instances, will get different IP addresses (and/or ports) since they may be running on different servers
So how do I test multiple instances of Web Apps in the Azure App Service that need to cross communicate in development?
...or am I just missing something big here?
Thanks in advance.
Dave A
You can use the ARRAffinity value to specify which instance you want to hit, allowing your request to hit any instance you want.
You can find more details here: http://blog.amitapple.com/post/2014/03/access-specific-instance/#.VhLIGXmFMis
Could you run full IIS (w3wp) locally for testing? If so, you could create multiple sites or applications using different application pools, and hence processes.
I found this. http://blog.tylerdoerksen.com/2013/11/01/azure-websites-vs-cloud-services/
In short, given that I need to have some internal communication then Web Apps in Azure App Service should not be used.
Related
Can I use one azure mobile app as a backend to support for mobile app and website?
I need it to support push notification and authentication as well as CRUD operation. Should I use API app or Mobile app or something else?
An Azure Mobile App is just a regular ExpressJS app with the Azure Mobile Apps SDK implemented. Here is a good example of a combined web + mobile:
https://github.com/adrianhall/azure-mobile-apps-html-quickstart
The 'public' directory contains the static website, complete with JS and CSS files. The app.js is your app (note the serve-static module usage to serve up the static content).
Now that Mobile App, Web App, and API App are under one roof so to speak you have several options.
They are all part of App Services.
The easiest way to think about App Services is in terms of a VM that hosts multiple web apps in isolation.
You create an App Service that is like a VM and then you create multiple apps that run in that VM.
You could create a Mobile App and a completely separate Web App that share a common database for instance.
You pay for the App Service instance, not each app, so it's really up to you how you want to divide up the functionality.
Now before someone cries foul on my VM analogy, I said it was the easiest way to visualize it, not the most accurate.
What you really get is a "Virtual Virtual-Machine" that could be one or many VMs. You see it as one logical thing in terms of management, deployment, etc. but it could really be multiple VMs. It can scale up or down based on your configured options (eg 1 VM always, scale up to 5 VMs if CPU or Memory exceed thresholds you set, etc.).
I have a azure cloud service (a server) where i host a Redis database. I also have a web site hosted in azure web sites. I want the web site to be able to talk to the Redis DB on port 6379. I know I can configure a public endpoint for that port on my server but that would open it for whole Internet. I want it opened only for azure web sites (or even better, only for my web site). How can i do this?
Windows Azure Web Sites is in an isolation bubble separate from your Cloud Services and there's no way to bridge that gap. Ideally you'd do this by connecting the web site machine to other Azure services via a Virtual Network, but this FAQ confirms you can't do that right now:
Can I use Windows Azure websites with Virtual Network?
No. We do not support websites with virtual networks.
Opening Redis up over the internet shouldn't even be considered as it doesn't have the kind of security you'd want out of the box to be opening up its port publicly as it is meant to be co-located with your application, so you really wouldn't want to do that. Never mind the added network overhead which will eat into the performance you expect to get by leveraging something like Redis anyway.
I believe your best bet given your current configuration is to add a Web Role that's part of the same Azure Cloud Service and run your web based application out of that so that it can communicate with worker role. It only requires a little bit of configuration to get this going (i.e. adding an InternalEndpoint to the Redis Worker Role). While I realize Web Roles don't offer as frictionless a development model as Web Sites, you have to choose the right tool for the job.
Another option, if you want to setup your Redis on a VM instead of tying it to the Cloud Service directly, is that you can setup a Virtual Network, put the Redis VM on the virtual network and then configure the Cloud Service so that it's part of the same affinity group and add the NetworkConfiguration/VirtualNetworkSite configuration section to the Cloud Service's .cscfg.
Which approach makes more sense all depends on how you leverage your Redis instance, but the main benefit of the latter approach is that the Redis instance is not recreated each time you deploy your Cloud Service and, so, any data that's in it will stay available between deployments. Another benefit is if you want to build and leverage a Redis cluster across multiple Cloud Services this enables you to do that.
We are looking to host a website (some css,js, one html file but not aspx, one generic handler).
We deployed in as:
1) Azure Web Site
2) Azure Cloud Service
Both solutions work. There is a question though: which way of hosting it is better and why? Second thing: as there might be a lot of traffic - which solution would be cheaper?
Thanks in advance,
Krzysztofuncjusz
You may want to review this article that explains the primary differences. Web Sites are best for running web applications that are relatively isolated (that do not require elevated security, remote desktop, network isolation...). Cloud services are more advanced because they give you more control over web sites while still remaining flexible. And VMs are for full control over applications that need to be installed and configured (like running SQL Server for example).
I think that main difference in abilities to modify VM and possibility to configure scalability. Web sites is something like classic hosting, without ability to login by rdp. Cloud Services allows you to configure VM and if necessary setup scalability and availability.
After working with Azure since one year still i didn't find any real scenario about multiple webroles under one application.
when we'll create hosted service at that time we need to select region as well URL of application so in our solution if we have created multiple projects(webroles/wrokerroles) then this URL map to which webrole/wrokerrole application?
As a end user webrole is a application but in Azure under one application we can host mutiple webrole applications!
Can anyone explain this Azure terminology and purpose of this also please give me some real scenario/example where we require this type of terminology?
Thanks in advance.
Multiple Roles are useful when your application is complex and you need to scale different things in different ways.
Different Web Roles might handle two different sites that make up one application, but that scale at different patterns (for example some BusinessAppWebRole and a AdministrationAppWebRole). Both of the apps are a part of one "system" and are deployed together and maybe even share some .DLL's or some such, but the BusinessAppWebRole might need to scale between 9am and 9pm and needs to be performing super fast for users, while AdinistrationAppWebRole might be doing some complex math or reports and needs its own scale pattern that should not impact the BusinessApp
Alternatively, you may choose to have a Website on one web role and a WCF service on another web role. Once again, both would be a part of the same "system" and deployed together, but have different usages and scaling strategies where a need would be to keep them on separate servers
Worker Role vs. WebRole is also a great example. Workeroles typically are background processors. Their goal is to scale based upon amount of work left to do. Customer-facing WebRoles need to have a different scaling strategy and must not be impacted by typically heavy/busy worker roles...
HTH
About your question having "multiple webroles" in one Windows Azure application, I personally do not see any specific reason for having two or more webroles in a single Application. Having two webrole in one web role will cause one role to use port 80 and some other port (8080 default) for other role. Because you will have one single VIP to handle two web role, you can not setup port 80 on both role. In some cases you can have such functionality plugged into one single web role configured on port 80 and 8080. I can think of one example of having two or more web roles in one application where user wants to serve hundreds of users from one specific web role which is configured to port 80 with several instances however other web role which is configured on port 8080 (other non 80) to admin site with 1-2 instances. I haven personally seen rare use of having multiple web roles in one Azure application however others might have some other view on this regard.
Having web role and worker role in one Windows Azure application is very common scenario in which you can serve content through a web server configured over HTTP/HTTPS and have a worker role to do background processing without suffocating resources on web server. You can also configure internal endpoints by defining specific ports in Web and Worker role to communicate between Web role and worker roles internally over TCP endpoints. In this scenario you can have number of web role instances to handling web traffic and several instances of worker role for background processing separately. The best example for such scenario is like having a web site where users upload video content from a web server and once the content is upload, worker role star encoding the video and when the video is encoded the video is available on web server for users to enjoy. In real world scenario if you have 1,000,0000 users using such website, you might end up having 100s of instances of web and worker role to facilitate overall activity.
just starting to explore Azure and I am still a bit confused regarding the purposes of web roles vs worker roles. In the solution I'm working on mobile apps (iPhone, Android, Windows etc) will be accessing our server product via a REST api. So there is really no public facing web site for our service (as in web pages).
This made me think that I don't need a web role but instead have one or worker roles listening on our http endpoints. I have created a prototype along these lines. When from a mobile device I do I an http post to the endpoint, I get no response back. And I see nothing in the Azure logs that indicate that indeed my worker role was started or is running and responding to it.
Is this an appropriate approach? Is there something I need to do in setup code because I don't have a web role? I read in another thread that web roles run in IIS but worker roles don't.
Thanks for bearing with me. I am still getting to grips with Azure and so have a little difficulty formulating the right question.
You don't need to have a web role in your azure deployment. As you read, a web role has IIS, and your web site is hosted in it. A worker role is basically a plain old W2K8 server without IIS. Honestly, I haven't RDP'd to a worker role instance, so I'm not 100% sure that you don't have IIS or not.
But you don't need a web role in order to expose a WCF service. Here's a nice example (although the background color needs some work) that shows you how to do this.
Good luck! I hope this helps.
Adding to what David Hoerster said: You can host up to 25 externally-facing endpoints (each with its own port number) on any role type, with each endpoint being http, https, or tcp. With a Web Role and IIS, a web application typically grabs an endpoint mapped to port 80. In your case, you'll be creating your own endpoints on your specific ports. You're responsible for creating your ServiceHost (or whatever you're using to host your service) and binding it to one of your endpoints. To do this, you'll need to either map each endpoint explicitly to a specific internally-facing port, or inspect the endpoint's properties to discover which port has been dynamically assigned to it, for you to bind to (might this be the issue you're running into with your prototype code?).
If you're looking for the benefits IIS offers when hosting your endpoint, you're better off with a Web Role, as it's going to be much easier for you to do this since a Web Role enables IIS by default (and it's easy to add WCF services to a Web Role from Visual Studio).
Even if you were to self-host your endpoints, you could still use a Web Role, but now you'd be carrying the extra memory baggage of a running, yet unused, IIS service.