One of the huge values for the enterprises is to provide support for companywide ability to create “developer” VMs. It would be great if company can go and buy “virtual teams”, or so many machines that could be managed and tracked as a group. For example a group per project. Many companies using consultants for the duration of the project and at the end of the project all of those VMs are no longer required. In real live the company continues to maintain supporting infrastructure, in Azure world this cost will go away. Ability to partition those groups further (QA, Integration, ….) will provide better accountability and usability. When in fact moving production data is associated with the congeniality and sensitivity risks, the offloading development environments with fake data (must be so) is HUGE value proposition. And the best part of it – it does not require highest performance from Azure as well.

This would allow you to upload your application(s) to the cloud but not be publicly available. Access would be enable via sign or perhaps an external ip range.
Load tests could be run against the applications using vs2010 test tools or other and a billing report could be produced based on a specific test window or just over a period of time.
This would allow developers to load and stress test applications, get a realistic picture of potential billing based on load but at no cost until go-live.
This is the only way I can see that I will be ale to justify the investment before I commit to Azure. I love what is on offer but we are only just recovering from the GFC and don't have money to burn. After all, I wouldn't by a Porsche without a test drive :-)

Currently Windows Azure Plafrorm offers SLA of 99.95% for compute service for Azure solutions that comprizes of 2 or more role instances.
However, very often Azure is used to prove untested business ideas. It does not make sense to have to pay upfront for high-availability and additional components (Azure AppFabric Cache for Session state, etc). A lot of ISV will want to go to market with one instance and if the business idea works - scale out.
So it would make sense that Microsoft defines an SLA for a solution comprizing of one role - obviously we would not expect 99.95% something like 90% SLA would be enough. For this to work we would also like that the updates in the datacenter do not happen during working hours in a given geography.
Regards,
Michal

When you're running a mission critical service in Azure as one or more cloud services, deleting the production deployments my mistake can become catastrophic.

Not only because the service is suddenly out, but also, and perhaps more importantly, because you lose your public IP address. In many cases (ours included) losing the VIP reservation means weeks of downtime because we integrate with lots of banks and insurance companies many of which have a rigorous and time-consuming process for opening up their firewalls for incoming and outgoing calls to the new VIP.

As long as you either always deploy to staging and then VIP-swap, or only do in-place upgrades of your production slot, you're fine. But if you should happen to delete the production slot... disaster.

For that reason, it would be valuable to have a protection mechanism in place. I'm thinking a setting per cloud service called "don't allow production deployments to be deleted in this cloud service". Enabling this setting would provide valuable protection.

Before I invest my money and efforts into the development for Azure, I'd like to know exactly how much it will cost me to host my application under this cloud. Here is the exact thing I'd like to know about: if I have a few Workers within my application, what will be the billing for those? I just do not want to pay for the Workers Uptime if they do not handle any requests right now. But, from the point of view of pull-oriented architecture of the Azure Queue, I do not understand how can I shutdown the workers in their idle time.