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.
Related
We currently have an Azure Cloud Service running one web role and two worker roles. As of now the web role consists of both a WebApi backend and a client web application running AngularJS.
We are now looking into the possibility to split the web role in two. One serving WebApi for the backend and one role just for the client application.
I've tried to have two web roles in the same cloud service, but it doesn't seem possible to have two roles bound to the same port (SSL/443) because they share the same public ip address.
I've seen solutions to have to sites in the same web role using host headers to differentiate them, but this isn't what we want.
What we want is;
Webrole1 - AngularJS client app
Webrole2 - WebAPI (SSL/443)
Is there any way of accomplishing this?
You may have several web roles in the same cloud service. However, you won't be able to use the same ports. You'd need to come up with different port mappings outside of 80/443, since the external-facing endpoints are tied to a specific role.
The only way you can take the host header approach is if you keep your functionality within a single role, as you currently have it.
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.
If Azure App Service plans are virtual machines dedicated to the Web, API, Logic, and Mobile apps defined within them, does that mean that a web app in an app service plan is an instance of a virtual web server in IIS on that virtual machine?
Assuming this is the case and that each virtual web site gets it's own application pool, is there an Azure scaling strategy or scenario where more than one worker process in that app pool will run, creating a web garden? My understanding of web app scale out is that it results in additional VMs being allocated and not additional worker processes.
The scaling strategy will depend upon the pricing tier you have opted for.
Basically each Service Plan will contain a collection of Web, API, Logic, Mobile apps. These will form a web garden within the Service Plan server you choose.
If you initially choose a single B1 Basic Service Plan, you will get a single virtual machine with all of your applications running on that. As the load on that server increases, you can scale it up to larger servers, but it will still be running on a single server.
If you then choose to create a second instance (and a 3rd, 4th, 5th...) that second server will be a replica of the first server, with the load being balanced between the two. (3,4...)
While I've not seen documentation for this, I would imagine that each Web, API, etc app is run under its own application pool / worker process, and scale out is simply duplicated instances.
I'm not sure what a Virtual Server is, but each app runs in its own dedicated application pool and w3wp.exe process. There is only a single w3wp.exe process per application pool, so no web gardens.
Is there a specific reason you think you need these to scale your apps? In most cases, using web gardens is the wrong way to scale, as adding more processes can cause unnecessary overhead (amongst other problems - you can find some useful resources on the web). You almost always want to prefer threads over processes for improving concurrency. If you're running out of physical resources (CPU, memory, etc), then the correct way to scale is to add additional VMs.
I have an application that includes multiple hosted services in Azure. Two are web roles, one is a worker role. The problem is, two of the roles need to now communicate. One is a web role that serves as the admin interface. The other is a worker role. The admin interface needs to issue commands, like pause any running jobs, report status, etc. The 2nd web role is just a site, unrelated to the first two.
(Just to preface, I want to make sure my use of Azure terms are correct):
Hosted Service: An Azure 'application'. Multiple roles with two deployments, production and staging
Deployment: A specific instance of all the roles, either in production or staging, with a single external endpoint (*.cloudapp.net)
Role: A single 'job', either a web role or a worker role.
Instance: The VM's that service a role
Also to verify: Is it possible to add roles to an existing hosted service? That is, if I deploy 2 roles from one solution, can I add a third role in another deployment from a different solution?
Because each role is in it's own hosted service, it presents some challenges. Here's my understanding of the choices in how they can communicate:
Service Bus: This seems to be the best from an architecture standpoint. Each hosted service can connect a WCF service to the service bus, and admin can issue commands to the worker role. The downside is this is pretty cost prohibitive.
Internal endpoints: This seems best if cost is factored it. The downside is you have to deploy all the roles at once, and the web roles cannot have unique addresses. The only way to access both web roles externally is with port forwarding. As far as I'm aware, it's not possible to deploy 2 roles from one solution, and 1 role from another?
External WCF service: Each component can be in individual projects and individual hosted services. The downside is there's now an externally visible service for administration.
Queue/Table storage: Admin can write commands to the Azure Queue, and the worker roles can write their responses to table storage. This seems fine for generating reports, but seems not great for issuing synchronous commands.
Should multiple roles that all service "the application" all go into the same Azure hosted service? If from a logical standpoint it makes the most sense, then I'd be happy to go with #2 and just deal with port forwarding.
First off, your definitions look pretty good and I think you understand the problem pretty well.
Also with each deployment, each external endpoint can only be assigned to one role. So if you want to run two sites on port 80, then they need to be in the same role. This is just like setting up two sites on an IIS with the same port (which is exactly what you're working with). The sites are distinguished using host headers. If you don't want to go to that effort or if you want to deploy the sites separately, then you'll want to put your stand alone site in its own service/cloud project.
For the communication part, the one option that you've missed off is service bus queues. Microsoft have released a library using service bus queues that is specifically designed for inter-role communication.
Other than that, the extra comments on your points:
You're right internal endpoints is the cheapest way to go, but you will be rolling it all yourself. Of course it could setup WCF services to listen on these internal endpoints.
An external WCF service might work OK, but if you have more than one instance of your role, all WCF calls will go through the load balancer and the message will only be sent to one of the instances. You would need to make multiple calls to make sure the message was received by all instances and even then you couldn't be sure it had worked without some other feedback method.
Storage queues suffer from a similar issue. If you have two instances and want them both to receive the same message, there's no way to guarantee that this will happen.
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.