Technical details about SQL Server Data Services (SSDS) are as scarce as hens' teeth, but following are posts about SSDS and/or competitive products by members of the SSDS team, other Microsoft employees, competitors, and relevant industry pundits that I'll be watching in case they spill some more beans.
Soumitra Sengupta: It is simple, but it is not SimpleDB
As I mentioned in an update to my SQL Server Data Services to Deliver Entities from the Cloud of March 5, 2007:
Microsoft's party line appears to be: "SSDS is not a SimpleDB compete," which was Nigel Ellis's answer to a question after his presentation. I doubt if anyone buys that line.
I don't believe blog and magazine writers are proclaiming equality of SSDS and SimpleDB as data services. However, there are sufficient similarities between the target audience of the two as to make them competitors in the scalable, schemaless "data store in the cloud" market. The fact that SimpleDB stores attribute/value pairs in hash tables and SSDS stores them in SQL Server table columns doesn't negate the fact that both offerings use XML as their data format, accept free-form attribute design, automatically index new properties as they are added to speed resource retrieval, provide a query mechanism, and offer SOAP as a service protocol.
Obviously, SQL Server's data engine and related Microsoft Data Platform technologies, such as Synchronization Services, ADO.NET Data Services, and LINQ-like query query language provide a richer data access layer than SimpleDB's basic SOAP Web service. I also expect Microsoft's charges for data storage and traffic will reflect differences in capabilities and accouterments between the two. It costs more to lease and service a Ferrari than a Focus.
Nigel Ellis: Introducing SQL Server Data Services (SSDS)
Nigel's BT08 Introducing SQL Server Data Services (SSDS) presentation to MIX08 is available online.
Ryan Dunn: Entities, Containers, and Authorities
Ryan kept his promise. His first detailed post describes what the SSDS team calls the 'ACE' concept: Authorities, Containers, and Entites. He then goes on to explain the URI semantics for addressing a resource:
For example, with replaceable parameters italicized:
returns the entire entity, SSDS's smallest retrievable or updatable unit, identified by its entityID key from the specified container.
The ?q= query string in
corresponds to a SELECT * FROM container, which returns all entity instances in the container. Presumably, there's a governor to prevent users from accidentally downloading a 1GB XML document from a million entity instances.
Soumitra Sengupta: My personal take - why I think SSDS is a big deal
Soumitra is another SSDS architect whose first post to the SSDS team's blog is an autobiography. It appears that cast in the SSDS blog's name, The Long Term Store cast, means cast of characters. Prior to joining Istvan Cseri and Peter Spiro, a Microsoft Technical Fellow, to create SSDS, Soumitra ran the Webdata XML team that delivered LINQ to XML and Visual Studio 2008's XML tools.
He echoes Istvan's comments about the fluid nature of SSDS:
[W]hat we are releasing is just a starting point and in the spirit of web facing services it is not where the service will be 3 months, 6 months or 12 months from now. We are going out early and our commitment is to work with our customers and partners and evolve the service quickly to where they need us to be.
Somitra said at the end of his post:
I did have more to say but this is already too long. So I am not going to go into the details of the service or the infrastructure we built to deliver it.
True to his word, he avoided delivery of any useful details.
Istvan Cseri: Live from MIX '08 - SSDS is live!
Istvan, who's a data architect for SSDS, posts a brief autobiography of his career at Microsoft and then concludes:
As we deliver on our Data Platform vision which this service is part of you will see more and more capabilities of the underlying SQL technology – we are starting with a simple but flexible data model which will grow richer over time just as the query capabilities will. You can access the service using internet standard protocols (REST and SOAP) from any platform.
In other words, the SSDS beta probably will be incremental with several CTPs before release. As noted in SQL Server Data Services to Deliver Entities from the Cloud (updated March 6, 2008) the SSDS API isn't aligned with the ADO.NET Data Services API, but Microsoft's Francois Ajenstadt says:
The goal is to bring the API's between SSDS and Astoria closer together closer to Release. Stay tuned.
Eugenio ported the Microsoft LitwareHR Software as a Service (SaaS) sample application's multi-tenant data access layer to SSDS. Here's LitwareHR's description:
LitwareHR is a fictitious HR application providing recruitment-management software delivered as a service. The most important aspect of this application is not what the application does, but how it does it. Using the latest Microsoft technologies such as .NET Framework 3.0 and SQL Server 2005, LitwareHR implements single-instance multi-tenancy patterns. These patterns, previously described in our whitepapers, are available in the MSDN SaaS Architecture Center.
Same client experiences (Web Client, Rich Client, APIs), same business logic exposed through WCF, completely new storage.
I'll post a link to Nigel Ellis's presentation, RBT05–Introducing SQL Server Data Services, when it becomes available, presumably tomorrow. (The scheduled session overflowed, it was one of the five most popular Thursday sessions. So it's being repeated at at 5:45 - 7:00 p.m. in Delfino 4005.)
Ryan Dunn: Introducing SQL Server Data Services
Ryan has been working on SSDS for the last three months, although he doesn't say what he was doing. However, he does say:
Over the coming weeks and months, I will be blogging more about the shape of the service as well as introducing some very cool samples that show off the power of SSDS.
So I'll add his blog to my feeds list and see what happens.
Jamie Thompson: SSDS is Microsoft's Amazon S3 competitor and SQL Server Data Services raises questions straightaway
Jamie is a developer with UK consultancy Conchango with a penchant for SQL Server Integration Services (SSIS). Like a few other observers, he considers SSDS as an S3 competitor. S3, however, is unstructured storage. SSDS and Amazon's SimpleDB are structured storage platforms despite the fact that neither exposes a traditional schema. I consider SSDS a SimpleDB competitor.
The maximum length of SimpleDB attribute values is 1,024 bytes, so S3 is the natural service in which to store larger objects/entities or blobs.
For more SimpleDB technical details, see my Amazon Announces Beta of SimpleDB Web Services in the Cloud of December 14, 2007, updated 2/14/2007.
Jamie's list of 15 questions are among those I wish that the SSDS FAQs had answered. There will be LINQ to SSDS, which presumably is the same as or similar to ADO.NET Data Service's LINQ to REST. I wouldn't expect stored procedures, SQL Server Analysis Services (SSAS) or Reporting Services (SSRS).
Robert Scoble: Amazon's Challenge to Business: Turn Off Your Datacenter
Robert interviews Jeff Barr, Amazon Web service evangelist, on his new (this week) Fastcompany.tv site:
Whenever we interview startups (which will be often here on Fastcompany.tv) we hear "we're an Amazon shop" quite frequently. What does that mean? Well, for photosharing service SmugMug it means saving a ton of money by having Amazon store all of its data on its S3 Web Service. We don't know of a technology that's changing the infrastructure of business faster than what Amazon's built, so we went to Amazon's headquarters to talk with Jeff Barr, Amazon's evangelist for its Web Services team, to find out Amazon's plans.
Jeff discusses SimpleDB as well as S3 and EC2 during the interview.
Update 3/20/2008: Removed embedded video player. Click the headline to watch the segment.