What's up with SQL Server Data Services (SSDS)? Presumably, we'll get to hear more at PDC on October 27th, when the SSDS team present their plans, but the current signs aren't encouraging.
When Microsoft announced their "database services in the cloud" at the launch of SSDS, we blinked with amazement. The prospect of being able to use SQL Server remotely, from any website, was intriguing. However, on closer inspection, the Authority Container Entity (ACE) architecture, replete with "flexible entities" and "flexible property bags", smacked of a new mysticism and served to mask the fact that it was just another EAV database.
The marketing blurb spoke of the freedom of not requiring database schemas, as if this was a cause for rejoicing rather than fear: 'Simply add new attributes to your data set when needed, and the system will automatically store, index, and query your data accordingly'. It all seemed a long way removed from the rigors of real commercial applications, and certainly at the 'wacky' end of the scale when compared to Amazon SimpleDB and Google App Engine (GAE).
Who, we wondered, was desperate to get hold of woolly, schema-less authorities, consistency units, containers and entities with only five primitive data types offering neither foreign keys nor joins?
Almost nobody, as it turned out. The Beta program was originally specially restricted, presumably in fear of people being crushed in the stampede. They needn't have worried. The answer to IBM's 'Blue cloud' turned out to be a 'black cloud' of depression. The beta was under-subscribed and later referred to as 'limited'. If one gauges public interest in SSDS from the SSDS forum, then it seems that the public is looking elsewhere.
There has been a degree of backtracking from the initial, heady days of radicalism but in many areas SSDS is still shrouded in vague and largely unfulfilled promises. For example, joins, which would imply support for foreign keys, are promised but there is no sign yet that we'll be allowed schemas after all. The promised LINQ library has failed to materialize; there is still no role-based security; we are promised a 'convergence' with Astoria (ADO.NET Data Services), JavaScript Object Notation (JSON) and the Atom Publication Protocol (AtomPub or APP), but the subject of client tools is still very hazy, with all developments now seeming to be directly using REST and SOAP as the interface.
If only SSDS had simply been introduced via an (Astoria) front end, the story might have been different. Rather than having to hack together a data layer using REST/SOAP, and committing to a lot of work that it would be difficult to roll back from, a developer could simply use Astoria and SQL Server for development work and then switch over to SSDS without changing any of their code. This would have provided a simple and "safe" migration path from on-premises database (SQL Server) to cloud-based (SSDS). At this point, the advantages of shared database-server resources kick in, in terms of the scalability, availability and consistency of their data tier, as well as the ability to expand capacity incrementally and to manage spikes in usage.
As always, we welcome your thoughts. If you think SSDS is wonderful, and its developers 'rock stars', if you've used the early releases of SSDS and think we're way off the mark, then please let us know about it. The best comment will receive a $50 Amazon gift voucher.
Cheers,
Tony.