mca blog

the blogosphere is buzzing about the announcement that Microsoft has changed direction for their SQL cloud offering. later this year they will drop HTTP and SOAP support and focus only on TDS transport.

i'm bummed out.

first, i think this is not the right decision. IMO, the long-term bet is on widely-distributed data. data that lives in multiple containers, is in varying formats, and is stored in scattered locations on the network. and TDS won't cut it for that. the adoption of the Entity-Value-Attribute (EAV) data model by Google (BigTable) and Amazon (SimpleDB) are solid examples of the future of data storage and retrieval. and they are not alone. CouchDB is another implementation that is gaining traction. my point is that MSFT had a solid start on an EAV offering and dropped it. not a good move.

i'm not dense. i understand their motivations for this change. MSFT has got millions of developers hooked the power of T-SQL thru their SQL Server offerings. rightly so. it's a great data server. and MSFT has made working w/ SQL Server easy through excellent integration work for their dev tools like Visual Studio. and they've spent lots of time and effort building multiple code libraries for the .NET framework that can easily talk to SQL Server. very nice. very easy. very old school.

and i'm not blind. while MSFT is reworking SDS, they continue to offer Azure Table Storage. ATS is an EAV that currently supports Atom and JSON serializations over the wire. the problem here is that MSFT's Table Storage API has less functionality than SDS did before the switch. for example, ATS does not support JOIN or ORDER-BY and, i have been told, there are no immediate plans to provide it. the other, more dangerous, downside of the ATS model is that it's built on MSFT's ADO.NET Data Services (Astoria) codebase. this is a very creative endeavor, but one that is flawed (IMO). too much of Astoria's functionality leaks into the URI requirements (it has it's own custom query patterns) and it's code requirements (currently you have limited control over output formats). in effect, Azure Table Storage *is* Astoria. let's hope Astoria doesn't change, too.

finally, this move away from the leading edge back to the 'weighty center' is just the opposite of what MSFT needs to do right now. while it may look like a smart move to make it easy for millions of T-SQL savvy devs to start using Microsoft's data services in the cloud, in the end, it is putting off the inevitable. and delaying the regrettable. it's inevitable that the data server model will yield to heterogeneous data models. it's regrettable that some of the tried-and-true features of relational data models (i.e. foriegn key constraints, cross-table joins) will not survive the transformation to processing widely-distributed data on the Internet. but that's the way things go sometimes.

in the end, it's all just data. and the immediate tactics employed by Microsoft or Google or Amazon are just a blip in the big picture. in the long run the trend is away from walled data and toward mixing information bits from lots of places. the good news is that, by switching to supporting TDS instead of HTTP, Microsoft customers will be able to take advantage of Microsoft's cloud offerings sooner and with less effort. the bad news is that, by sticking w/ TDS, Microsoft and its customers run the risk of falling behind in the broader trend of storing, sharing, and leveraging data in the Internet.

oh yeah, me? i'll keep pushing for better EAV support from Microsoft. and i'll be brushing up on my SimpleDB skills.

and that's a bummer.