While I like the ideas in the "Azure Compute Small Business Edition" discussed below (and think it should be implemented) I really feel strongly that allowing multiple roles (of any combination) within a single VM is a must. As some have noted Azure is charging us for a full VM at market rates but doesn't give us much freedom to fully utilize that VM. By allowing us to host multiple roles within a VM we can better make use of the available compute power.

For example in my case I'd like to host a single web site that gets fairly low usage and a set of 3 or 4 low volume web services all in a single VM. Then as any of them gain traction I could parcel out one or more roles into separate VM's.

This gives me flexibility and allows me to manage cost. The current 1role to 1VM limitation is a significant roadblock for me.

This is a feature that would be very helpful.

We have an application that has many lightweight and busy windows services all interacting with one database. Some process many thousands of transaction per day and other could just schedule a job once per month/day…….

The reason for having many services is the ability to, switch them on and off/upgrade independently without affecting the other running services. We are looking at moving our application to the cloud, but if I understand correctly will have to pay for an instance for every service?

This could become very expensive?

This is actually not excactly the same as "Make it less expensive to run my very small service" as that suggestion raises a lot of isolation and security concerns when the kernel has to be split by different users and therefor is a lot harder to implement and realise.

I'm gladly paying 60$/month for a compute instance, but I would like to be able to run several applications in this instance. I think this should be a lot easier to implement for you guys as this does not raise privacy and security concerns :-)

Thumbs up, +3

Providing Many (*) Roles per Instance is actually very important to the future success of Azure. It's perfectly normal and reasonable to have several smaller sites/services that you want to piggy-back off of your existing clustered environment. Based on Azure's current model, it's virtually the equivalent of having to create a new dedicated machine for every single role (web or worker) we deploy, which is quite ridiculous.

Even if my services were to scale well beyond a single VM, I still want all my services to take advantage of the highly scalable environment that my more dominant roles are responsible for (due to their workload requirements).

In a nutshell, it should be the choice of the deployer on how they want to partition out their roles. If I want to squeeze a hundred small websites, and a hundred small worker roles into an environment with 5 VM's, that should be our choice, as we're the ones paying within your already existing payment model.

This problem is a technical constraint (or configuration constraint, if technically already feasible), and does not really conflict with the payment model already in place.

Having thought about this a bit more today I don't think having full desktop access to a VM is the way to go and it isn't really needed. The whole point of Azure is seamless scalability which would become more difficult should we play around with the VM's themselves. The way we deploy and manage Azure applications at the moment is probably the best, although expensive considering it doesnt give you full access to a machine as you get with Amazon.

I guess in the simplest form what we would be looking for would be that every role in a "Windows Azure Cloud Service" project would run on the same virtual machine still with the ability to choose 1 to 2000 instances all running the same configuration for load balancing purposes. If we want to run a role on a seperate instance we would create another cloud service project for it and add the role to that project instead. This would move the instance configuration to the cloud service project instead of the role.

The web roles would need to be able to map which domains apply to each web role, there could be more than one domain as well as wildcard subdomains mapping to a single role.

We would also probably need to have some sort of performance monitoring view for the memory and cpu utilisation of the instances so we can see when we need to change from a Small instance to a Medium one or to try and split out parts of the project to run on their own instances if they start doing well.

For those who want to make sure each application is isolated from each other they can still do that by creating a cloud service project for each role they want to keep seperate. The only downside I see would be if they wanted to share configuration across those projects...

I just posted a reply on the forums about another problem but it outlines how we would like to use Azure as well which relates to this so I thought I'd re-post it here as another example of how multiple roles per instance would be beneficial to us.

Ideally we would like to have each area of our application as a separate project to keep them in logically defined units and share the common libraries but Azure's pricing and resource structure doesn't allow for this. Our application is split into 4 (possibly 5) areas, each area needs to run on port 80 but being accessible from different domains. Same application, different front ends for different types of users. From what I understand we would need to have 4 or 5 instances running, 1 for each area/project.

Each area would only use about 10% or less of the available resources of a Small instance (until traffic grew and we need to scale up). So that would mean 4 or 5 instances each using 10% of their available resources (or looking at it another way, wasting 90%). A single instance would be more than powerful enough to run all the projects at the same time with room to spare.

That also means that the cost would be multiplied 4 or 5 times, ($90/m * 4 instances = $360/m) when a single $90/m instance would perform perfectly well. Add on to this that we need 2 instances for each area for the SLA. That's $720/m and for the amount of resources the apps are using it is a lot of wasted money.

I hope I am wrong though because it just doesn't seem right, there must be thousands of people wanting to run smaller apps which could grow quickly hence needing to be run in the cloud or wanting to make best use of the resources available and the features of Azure like the queue and table storage, etc. It would be better to have full access to a single machine where we can configure IIS ourselves like with Amazon EC2. Unfortunately EC2 costs $800/m just for a SQL server but the cost and flexibility of hosting the actual apps on Windows on EC2 seems substantially better...

To get around this at the moment I'm using an MVC 2 web app with each part of the project in its own area and using custom route constraints that check which domain is being used to route it correctly. It works but I'm not totally happy with having to do it this way.

We also have to have a worker instance running 24/7 which sits there idle and only runs jobs at 2am, this is another massive waste of resources and money as there is no need to run this on another instance it could easily be run on the same instance as the website or be invoked by some sort of cron job to start an instance which runs until the job completes.

Amazon is demolishing you on the pricing front. As I see it, you have two options.

Option One (VM Pricing): Recognize that you are charging market rates for a full VM. Charging market rates for a full VM is a perfectly reasonable thing to do, if you just listen to Mike Plate's suggestion and give us an actual full VM for our money. Simple as that. Everybody's happy.

Option Two (Application Pricing): Keep the granularity where it is (at the application level) and bill us appropriately. Stop billing us "deployed hours" for a full VM and start billing us "running hours" for an application. My web app is idle 90% of the time, and when it's not idle it consumes on average 1/8th of a VM. Bill me market rates for the 10% * 1/8th of a VM that my application actually consumed. Charge me market rates for the services I consume and again everybody's happy.

Note that I haven't set up any complicated tiered pricing models or tried to justify any nonsensical price points ( r0x0rZ ! FrEe C0MpUtInG 4 3v3ry1 ! ). All I've done is observed that Amazon has set the market price for a small VM at about $80/month and recognized that Azure needs to be competitive with market pricing.

If you really, really want to make the pricing model complicated (not because it's a good idea, but just because that's what Microsoft ALWAYS does), don't give us Joni's arbitrary (and complex and never optimum for anyone) suggestion, just give us Application Pricing with a sliding rate scale. We're reasonable people and we do understand that things frequently become more economical in larger quantities. You could, for example, charge us $0.25 or $0.50/effective-compute-hr for low consumption applications (that's right, I'm suggesting you could raise satisfaction levels by charging customers 200%-400% over market rates) with billing steadily declining to $0.12/effective-compute-hr for high consumption applications.

I personally think real application pricing would be better than VM pricing, but I can totally make VM pricing work if that's easier for you to implement. Until you find a way to get your offerings in line with market pricing, though, you're dead in the water. I'd really like to start using Azure and there is no way I can justify burning $170/month to run my app on Azure when I can run it on EC2 at a cost of zero additional dollars out of pocket.

The economics really are that simple.

I don't think the "Azure Compute Small Business Edition" or express one will solve our issue. The requirement is that we need to keep trying quite a number of apps, while we have no idea which one of them will be a success and when they will succeed. And every app needs to be always available since there are users using every one of them at any time.

The motivation behind this feature request is that we can keep adding new apps without adding additional costs. All we need is 2 instances to get 99.95% availability for all our apps. If any of the apps getting popular, we can always scale them out to use more instances.

But with the "Small business edition", we are still adding costs if we want to add apps. So we are not able to scale out regarding app numbers. The "Small business edition" actually addresses another different issue about reducing the minimum expense on Azure to have something online 24*7, which is another valid concern.

Another point is that by allowing multiple roles per instance, we are able to share the resource we purchased as much as possible for all our apps while still get the benefit that we are isolated from other Azure users and not affected by their apps.

I think @Mike Plate is on the right track. These instances run in a VM that is taking using disk, memory, CPU, and network usage and $0.12/hour is extremely competitive pricing. From a resource standpoint it is difficult to find a VPS with the specs given for this low of a price. There is even more value when you consider how easy it is to scale up and down. The pricing isn't an issue.

The issue is that while I don't mind paying $86/month for an Azure instance, I'd sure like to get the most out of it. IIS has been able to host multiple applications for a long time, so I'd hope that being able to run multiple web roles in an instance would be possible. I presume that worker roles get hosted in their own processes, which should cleanly allow multiple roles to run in an instance.

Mike, your assessments for "Azure Compute Small Business Edition" would work well for us.

The only question I would have (unless I missed it) is, when you say you cannot have several slices, are you talking about not having several instances or not having several CPU time slices within a single instance?

I ask because I would probably want a few instances under this package, to host a few, services unrelated to one another. (Like a service that I use once an hour to run a field assessment report and another service, running all the time that runs a customer information portal; both being unrelated to one another).

As far as storage and SQL Azure is concerned, the currently pricing model isn't really an issue for us. The biggest turnoff has been the compute service pricing.