The pricing for Windows Azure has been out for a little while, but I found it unclear exactly what you were paying for - especially for hosting web applications. What does $0.12 per hour really mean? That's CPU hours, surely? Well no - it turns out it's bad news: that's $0.12 per hour per web role or per worker role. And an hour is an hour: for every hour that goes by on your watch, you pay $0.12 for each role you have running.
That makes things very expensive very quickly if you're hosting a small web site, but this isn't what Azure is for. This gets very cheap very quickly if you're running Facebook.
This is also a great pricing model if your site has massive spikes in usage: ticket sales apps or tax service sites for example. You can basically turn your site off for 95% of the time, then spin up 20 servers in the space of a minute just before the tickets go on sale and drop back to zero just after they're sold out.
I think a more common route into using Azure will be for data storage. Data storage of Blob data is only $0.15 per GB per month (plus $0.15 per GB downloaded). If you've got a whole load of video or other media that you want to be constantly available, Azure could be a great dumping ground for it all: it's reliably available and isn't going to use up your bandwidth, and you can leave the rest of your app running outside Azure in an environment you're more comfortable with.
Using SQL in the cloud, however, is far more expensive than raw data storage: though prices are measured by the size of your database ($9.99 per month for a database up to 1GB; $99.99 for up to 10GB), what you're really paying for is all the functionality (and CPU time) of having a structured database. You've got to know that your database is going to be used regularly before this becomes worthwhile.
Oh thank goodness! Microsoft listened to everyone last year saying that accessing SQL Azure via REST was a major pain in the body part. We also now have everything you'd expect in a proper fully-functioning SQL database: gone are the days where you just have basic tables with string keys, partitioned by rules you specify.
Instead now you access SQL Azure via SQL Server Management Studio: you just connect to [database name].database.windows.net, and very nearly all the functionality you'd expect from SQL Server is right there. There are a few exceptions: for example you can't use the USE keyword, as they can't guarantee your two databases are on the same physical server (though they are on the same logical server) - in fact they probably won't be, to optimise performance.
A server is only a logical server - not a physical box. It's a unit of authority and a unit of geo-location, so this should be what drives the point at which you make another server. As you get to choose which datacentre's hosting your database, you can also get best performance by ensuring your application runs in the same datacentre as your database. And as data transfer within a datacentre is free, so you won't be eating into that $0.15 per GB download cost.
There's a nice improvement to security too: your server now comes with a firewall, allowing you to restrict access to by IP address range. Somewhat novelly, you can't create accounts called sa, admin or root, just because those are most commonly hacked.
(And next week they'll announce that you can replicate from Azure to SQL Server but shh! - you're not allowed to know that yet!)
The Developer General Sessions at TechEd are attended by pretty much every developer at the conference, so they're held in the largest hall on site.
"Wi-fi access is not available in this hall"," said the sign outside. A shame, because the main part of the talk was really quite dull, very high-level and largely uninformative. "VS2010's made of WPF!" My cat knew that - and I haven't even got a cat.