Awesome as usual!!! Paper outweighs all other stuff out there on Azure. One question, going forward how will one choose among Storage services & SDS. Has microsoft again made a mistake of building something (storage services) that might be phased out after v1.
 

I'm glad the paper is useful for you, Niraj. About storage: Windows Azure Storage and SDS address quite distinct scenarios. SDS is a traditional relational database, while Windows Azure Storage provides blobs, queues, and tables.

Blobs and queues are obviously different from relational storage, and even though they're called "tables", Windows Azure Storage tables in fact provide scale-out storage. They're more like Amazon's Simple DB or Google AppEngine's Datastore than relational tables, and they're intended primarily for scenarios that require working with really large amounts of data. I wouldn't expect any of these things to be phased out--each one has a distinct purpose.
 

Adding SQL data storage to the Azure Hash table storage is needed to deal with legacy apps. But business is fasts moving from transactional to emotional by way of sentiment analytics captured in unstructured fashion. What will this mean for the Visual Studio Developer? A new persistence model selected when implementing an app; select SQL data for real time integrity; select Hash tables for massive volume Sharded over multiple data stores?
 

I basically agree: Scale-out storage, e.g., Windows Azure Storage tables, will often be the right answer for really huge data, as they let you avoid creating and managing your own sharded environment. Traditional relational data will be the best choice whenever possible, though, because it offers so much more functionality than the scale-out mechanisms.

But I'm not at all convinced that relational storage is purely (or even mostly) for legacy apps. Why wouldn't a new app use relational storage whenever possible? Unless the app needs massive data scalability (and most apps don't), relational storage is still more attractive.
 

Good point on realtional storage. My point is, try selling transactional apps, few businesses are buying, because there is not enough new added value over current legacy apps. Meanwhile the world has moved onto apps guided by analytics data and sentiment analysis. Case in point Google knows far more about its Google Docs users than Microsoft knows about its Windows Office customers. The difference being all the analytics data captured on the web. Azure needs to empower developers to code the business basic while providing the sentiment analysis to really know how the apps are being used, can be improved. Same applies to web stores, we need to empower real time decision making around transactions. We need buckets of data to see patterns. Now we differentiate a new generation of apps and enterprises will buy added value.
 

Clive, you're really arguing that ISVs should prefer creating new SaaS applications over new on-premises apps. I largely agree: In lots of cases, such as those you name, cloud-based apps can provide more value. If these SaaS apps need massive data scale, using standard relational storage won't work.

And many on-premises software markets, such as those you characterize as transactional, are quite mature--selling new stuff is hard. Still, enterprises that want to build custom apps for their own use don't need massive scale. For these--and I believe there will be lots of them--familiar relational storage will be a better choice.