Over on the SDS team blog, they've just dropped a bombshell - v1 of SDS will essentially be a fully relational database in the cloud!
.given the feature set we are planning to support in SDS v1, a majority of database applications will "just work", allowing developers to target on and off-premises deployments with essentially the same code base.
Why is this such a big deal?
This change to SDS removes what I consider to be the largest barrier to entry - data persistence. Assuming that you've got an existing application that uses a traditional database, it would take a significant effort to refactor it to use either the Azure table storage or SDS. That is also assuming that the limited query capabilities of one of the storage services met your needs. Once the announced changes are posted, it becomes much more feasible to run an existing application in the cloud.
The ambiguity between SDS and the Azure table storage has also been resolved. As those two systems exist today, it is difficult to explain the difference. The best explanation I've come up with is that while you can create 'relationships' using either service, SDS allows you to query against those relationships without having to fetch part of the relationship first. Now the difference is clear - SDS is a relational database, Azure table storage is highly scalable entity storage.
A word of caution.
While this does considerably lower the barrier to entry, it is critical to remember that simply hosting your application in the cloud does not mean it will scale! A poorly designed database will still perform poorly in the cloud as it will in your own data centers. It is the developers' responsibility to make sure that it can handle the expected loads. SDS can now provide a highly available, highly accessible, redundant database, which is both extremely difficult and expensive to do on your own - it is not a magic bullet!
The Azure Services Platform is an amazing set of services, but my feelings are that the concepts and patterns it encourages are its most significant attribute because they promote scalable designs. It is critical to remember that at scale, things behave very, very different. I've personally experienced this on two projects, and in both cases the scale we were experiencing was never tested. Whether or not you deploy on Azure or in your own environment, these concepts and patterns are applicable, and can lead to more scalable designs.
