Will Microsoft Azure promote efficient software development?

Microsoft's announcement of Windows Azure pricing confirmed a lot of speculation about the nature of Azure and its target audiences.

First, Microsoft plans to compete directly with infrastructure-as-a-service (IaaS) vendors, especially market pioneer and leader Amazon Web Services. As CNET's Ina Fried reported:

On a pure consumption basis, Microsoft said it will charge 12 cents per hour for computing, 15 cents per gigabyte for storage and 10 cents per 10,000 storage transactions. For network bandwidth, the software maker is charging between 10 cents and 15 cents per gigabyte.

Interestingly, The Burton Group noted on their blog that something is missing in Microsoft's initial pricing for consumption:

As you might expect, the compute model is similar to EC2 in that the pricing is "per hour" and per GB. The missing part in the model is the size (or type in EC2 terms) of the compute platform. I would expect Microsoft to augment pricing for compute based-on the amount of compute resources an application requires.

That is a pretty glaring omission. I wonder if it reflects the maturity of Microsoft's virtualization technology, or if the company is holding back some interesting details about how varying compute demands will be handled. I expect we'll find out when the company holds its Professional Developer's Conference in November.

Second, like Amazon, it's an IaaS offering that really verges on a platform-as-a-service (PaaS) model: targeted more at developers than traditional system administrators. The proof is in the importance placed on .NET services, and the way messaging and access control operations are priced. The Windows Azure Platform Pricing and Licensing Overview states:

• Messages = $0.15/100K message operations , including Service Bus messages and Access Control tokens
• Bandwidth = $0.10 in / $0.15 out / GB

Interestingly, that page positions these services to be about integration with existing, on-premises enterprise software systems:

Messages (Includes Access Control, Orchestration, and Reliable Queuing for message): .NET Services allow developers to easily connect their cloud applications and databases with existing software assets and users. This connection between cloud and on-premises assets is facilitated by the exchange of messages. The consumption-based pricing model means that customers will pay only for the number of message operations that their applications use. The definition of a "message operation" includes Service Bus messages and Access Control tokens. Messages are charged to the customer in discrete blocks of 100,000 ("100k") for each monthly billing period...

However, if I read this right, any request to the Azure access control system will count as a .Net operation, resulting in a charge per 100K operations. (Bandwidth charges are also charged, but I am assuming that is only so if the message is sent or received outside of the Azure service.)

Which brings me to the point of this post. Will Azure force developers to be much smarter about their use of network bandwidth and .Net services than they would be otherwise? Is this pricing a sign that we are returning to the world in which resources will be carefully rationed amongst operations, and that efficiency reigns supreme? Will companies compete on the efficiency of their developer's architectures and implementations?

Do cloud computing services like Windows Azure or Amazon Web Services encourage better software development, or will they have little effect on the quality of commercial software?