Provide multiple roles per instance
Enables you to host more than one application on one Azure compute instance. Suitable for small departmental servers.
Create a new sandboxed webrole model that can by deployed and run on-demand. When not used the instance can be moved to 'standby' mode therefore reducing costs. New WebRoles could be created based on demand to provide an automatic scaling solution.
Doing this should decrease costs and improve effeciency. It will make Azure a true multi-tenancy PaaS solution.
I understand that Azure plans to provide multiple web roles per instance. But, Azure also need to provide multiple worker roles per instance.
I see no reason to have an instance for each role, when my roles are sitting idle most of the time.
If a Role is .NET only then a whole VM is overkill. How about having the option to deploy a role to a Process or AppDomain. This should be cheaper to run and make deployment much faster.
Windows Azure Websites offers the ability to have smaller deployed websites. The ability to have multiple roles on a single VM instance is still in planning.
Do we have any updates on this? Can I run more than on role per single VM instance?
Does no one at MS ever look at these?
Joe Wood commented
Agreed. A sandbox model (app domain) would suffice for 'safe code'. Using this we could support dynamic deployments and on-demand scaling.
Joe Albahari commented
If this is supported, PLEASE make sure we can add / remove roles without deleting the deployment!
John Williston commented
Most of my projects so far involve a web role with multiple web sites with the need for some behind-the-scenes automation, the result of which is that my clients get stuck paying for an extra instance that does next to nothing. It's really cost inefficient, from a client perspective, to have to buy multiple instances when one will do. Please add the ability for us to put worker roles on the same instance as web roles.
William Stacey commented
+2. Way it is today, you are forced to get a new instance for every role. That makes little sense and no scale for user. If I am paying 24/7 for a bucket, I want to fill that bucket as much or as little as needed. Same goes for Staging. Why require a separate instance for that? One should be able to deploy to that role to same instance.
David S commented
This would be hugely helpful for the way we'd like to deploy. Not to mention the extra cost incurred when we don't need to separate out these roles.
Emmanuel Huna commented
I am running a web role hosted in full IIS, with two different host names working under IIS. It works great.
Admin mode and full IIS does not allow multiple host header with https. Multiple WebSites in same instance is complete useless without this feature.
I run a startup and our budget is very limited. If I was creating my product for Windows Server, I would create multiple Windows Services (IE multiple worker roles) and run them all on 1 server. Since my budget is limited, Azure is forcing me to create one worker role that contains the functionality of multiple roles. I see no reason to have an instance for each role, when my roles are sitting idle most of the time.
Arnon Rotem-Gal-Oz commented
If you deploy multiple business services (e.g. SOA) then the logical mapping is service per worker role - but that's not cost effective so you cram them into a single worker role and then have to manage the liveliness and elasticity yourself - missing a lot of the reasons (operations costs) to move to the cloud in the first place (not to mention the extra development)
Fabio Ferrari commented
It is not a matter of multiple IIS sites... we shold be able to instantiate for examle 1 web role and 1 worker role on the same instance
I fully support the idea of having web and worker roles running onto 1 computing instance. I am a student and currently I am working on Azure, mostly for educational purpose and I have only 1 instance that I can use. So I have to think of workarounds in order to have some background processes in addition to a web role. In this line of thought small companies would need such an option when choosing a subscription plan.
I second Daniel Pamich's comments.
Daniel Pamich commented
I would also like web and worker roles to be deployed on the same compute instance. This enables small sites to get up and running cost effectively and then as the site expands and as required the worker roles could be split off to separate instances.
Also with web & worker roles on one instance small/starter sites could have the correct software architecture from day 1 and more easily scale as the site grows. Thus making azure a more attractive platform.
Brian U commented
So, when you say "full IIS", does this include the ability to use the net.tcp binding, or no?
+1 for what Paul Brown said. I should be able to logically design services, and deploy them on any number of physical instances and/or overlap them when required.
Second Paul Brown and CuriousGeorge.
I agree with Paul Brown. Ideally I would be able to take separate Role projects in VS2010 and assign them to a single instance. For example, a ASP.NET web app as one project and a separate WCF service app as another project. For a small scale system I'd like to be able to configure both roles to run on one instance, while maintaining separate VS2010 projects for them. Similarly having two worker roles as separate projects and allowing me to assign them to one instance.
Paul Brown commented
This is indeed good news, however, what about something similar for worker roles? I think what I'd like to see is the ability to architect your application as a number of web and worker roles and then to choose at deployment time whether all roles run on the same compute instance, or all web roles go to one compute instance and all worker roles go to another or any combination thereof. I think in some ways if you consider how BizTalk Server has a rich hosting model and allows you to enlist artefacts such as adapter handlers and orchestrations against one or more hosts, I see the same configurability of combining or separating web and worker roles across compute instances as and when demand requires it.