 |
|||||||||
|
|||||||||
|
|
This morning I was reading this blog entry and got pretty excited. My biggest problem with SSDS vs. Azure Storage was that the line was too blurry. Expecting people to be able to rationally make a decision between the ACE (Authority, Container, Entity) model of SSDS and the keyed-entity storage model of Azure Storage was putting the burden in the wrong place. Worse, in every discussion I had with people about it, including Microsofties, very few could actually come up with compelling arguments as to why to use one over the other.
Now that confusion is gone. In an effort to drop the confusion levels, they are going to stop supporting the ACE model and will instead be exposing SQL Server (or something that looks, acts, and talks like it) in the cloud using TDS (Tabular Data Stream). So why is this a good thing? Well, with the "old" (funny how we say old for things that never made it out of beta...) ACE method the access method for your SQL data was proprietary (XML , sure, but still proprietary in the sense that it didn't work out of the box with anything else). By exposing SDS via TDS in the cloud, we automatically gain compatibility with:
What this really boils down to is that when you are building your cloud application, you should be able to flip a switch and go from on-premise SQL databases to off-premise SQL databases. Anybody who has tried to make a decent prototype using the ACE bits of SDS knows how much of a pain in the ass the whole dev->build->test->stage->prod life cycle was going to be. Now it should fit in nicely with your current tools and process.
An added bonus is that they are going to be using Astoria to expose REST endpoints on this. This is a good thing because in classic Microsoft form they had two teams working on essentially the same thing (SSDS was building their own REST endpoint system...even though Astoria has been around longer and works with the Entity Framework).
This leads to my final conclusion - If you can build locally against a local SQL server and then push your code to the cloud with Azure SDKs and flip a switch and point to your cloud-based SQL server, then you can also use Entity Framework code in your client for both on-premise and off-premise databases. Sweet.
