5) The reason you’re billed is that once a VM within the Azure fabric has been allocated for your application, the CPU core and memory for that application can no longer be used by any other application. So it makes sense to bill for it immediately, even when the application is not running. However, there are supposedly future Azure deployment options that may not have this dedicated model could presumably bill differently.

>>I agree with you on the technical explanation. But as a PaaS consumer, I don’t worry about VM’s. Like Google App Engine, why can’t Azure virtualize CLR and make it multi-tenant than allocating a dedicated VM? I am very sure that CLR virtualization will offer more agility and flexibility.

4) There are different methods to creating a subscription on the platform. But once you’re in, the billing methods are pretty straight forward. Any user can hit the MCOP portal and sign up for a subscription just by using a credit card. The only hidden details have to do with fine line regarding what is considered a billable bandwidth and a ‘transaction’.

>>I feel the subscription model can be much simpler that what it is today. If MS wants to offer specialized packages to partners and academia, they can do it offline by providing redeemable coupons. But the pricing landing page is not subscriber friendly.

3) I can’t and wouldn’t argue about this one. Deployment is the least stable aspect of the Azure platform. Hopefully this will be cleaned up sooner rather than later and integration points for deployment will increase. There’s also the issue you don’t mentioned about H&A monitoring and integration with on-premise systems.

>>I agree that the deployment is stable but it is just not agile. If I have to consider moving my ASP.NET application hosted by a hoster to Azure to exploit the native code execution and full trust, The experience and agility should at least match the hosting experience. I am willing to take the hit if I get into heavy native code because of which Azure may have to dedicate a VM. But for plain vanilla web apps, the current latency is way too much!

2) this is actually in the works I’ve been told. Expect to see it soon. But is this really a big enough issue to be on a top 5 list? I’d much rather have greater reporting on individual instances and the ability to restart them on command.

>>This matters to paid subscribers because the configuration file is a sensitive thingy to handle. The experience and reliability are important factors.

1) kind of a repeat of aspects of #3. And while one-click deployments are nice, they don’t really work in enterprise environments. So I’m ok with the current mechnism or using any of the powershell scripts already in place to handle my deployments. There’s also folks that are automating TFS deployments to the cloud using these approaches.

>>I strongly feel that MS can do better on this front. After all, they own the platform and tools and can provide a stable, productive way of deploying apps. Visual Studio should be the best tool and front end for Azure.

5) The reason you’re billed is that once a VM within the Azure fabric has been allocated for your application, the CPU core and memory for that application can no longer be used by any other application. So it makes sense to bill for it immediately, even when the application is not running. However, there are supposedly future Azure deployment options that may not have this dedicated model could presumably bill differently.

4) There are different methods to creating a subscription on the platform. But once you’re in, the billing methods are pretty straight forward. Any user can hit the MCOP portal and sign up for a subscription just by using a credit card. The only hidden details have to do with fine line regarding what is considered a billable bandwidth and a ‘transaction’.

3) I can’t and wouldn’t argue about this one. Deployment is the least stable aspect of the Azure platform. Hopefully this will be cleaned up sooner rather than later and integration points for deployment will increase. There’s also the issue you don’t mentioned about H&A monitoring and integration with on-premise systems.

2) this is actually in the works I’ve been told. Expect to see it soon. But is this really a big enough issue to be on a top 5 list? I’d much rather have greater reporting on individual instances and the ability to restart them on command.

1) kind of a repeat of aspects of #3. And while one-click deployments are nice, they don’t really work in enterprise environments. So I’m ok with the current mechnism or using any of the powershell scripts already in place to handle my deployments. There’s also folks that are automating TFS deployments to the cloud using these approaches.